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This  paper  describes  the  development  of  a  user-friendly, 
syntax  directed  input  module  of  a  computer  aided  design 
system.  Color  and  dialogue  are  used  to  maximize  user  under¬ 
standing  and  ease  of  interf ace*  and  minimize  the  opportunity 
for  error.  As  a  result,  it  is  possible  for  the  user  to 
concentrate  on  the  higher  level  aspects  of  the  design,  and 
allow  the  system  to  handle  the  routine  details. 
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I.  IS  TBODOCTION 


4.  TBS  EEOELBM 

Computers  are  tocls  to  be  used  by  people  to  make  comple¬ 
tion  of  tasks  easier  and  more  efficient.  Yet  work  is  just 
now  teirc  dene  to  make  it  easier  for  people  tc  use  tie 
computers  which  are  assisting  them.  With  the  variety  of 
horn  computer  systems  and  languages  available  it  appears 
that  it  will  03  a  lcr.g  time  before  sufficient  training  is 
availaole  tc  provide  computer  literacy  for  all  whe  want  or 
need  it.  The  result  of  this  is  taat  two  distinct  groups  of 
computer  users  exist  -  those  who  write  programs  for  specific 
needs,  and  those  whe  use  the  software  packages  produced  by 
tne  first  greup. 

Eut  ac  users  and  user  needs  always  fall  into  these  two 
clear  cut  greups,  or  is  there  a  need  for  a  means  for  users 
to  tailor  software  to  their  individual  needs,  or  writs  their 
own  without  becoming  programming  experts?  One  no  longer  has 
to  D e  an  expert  mechanic  tc  know  more  about  a  car  tnan  how 
to  drive  it.  Dees  cne  have  tc  be  a  computer  programmer  in 
order  to  make  full  use  of  the  resources  and  services  of  a 
computer?  In  the  last  decade,  as  computer  cost  has  dropped 
and  use  of  computers  aas  become  more  common,  various 
attempts  have  been  made,  and  continue  tc  be  made,  tc  make 
access  tc  computers  easier. 

Twc  areas  exist,  in  both  technical  and  non-t schnical 
fields,  where  non-programmers  are  using  computers  exten¬ 
sively  as  means  to  deal  with  a  large  volume  of  available 
inf  or  ma  cion  in  an  interactive  manner.  The  first  is  in  use 
cf  query  languages  tc  access  a  database.  The  second  is  in 
computer  aided  design. 


B.  f  BE  VICOS  ATTEMPTS  AT  A  SOLUTION 
1  •  £J2££2  Languages 

Cne  proposed  solution  to  the  above  problem  came  in 
the  examination  of  ways  to  simplify  access  to  an  online 
bibliographic  retrieval  system  [Hef.  1].  Users  of  the 
system  had  to  learn  a  different  interaction  language  for 
each  different  computer  system  involved  in  the  network.  The 
guestions  were  raised  of  whether  the  needs  of  the  computer 
or  the  user  should  be  given  highest  priority,  and  whether  it 
would  be  possible  tc  standardize  or  at  least  reach  seme 
compromise  on  access  languages  the  user  would  need  tc  knew. 
Five  solutions  were  proposed,  covering  a  range  of  alterna¬ 
tives.  In  a  totally  non-user  oriented  approach,  the  user 
could  be  required  to  learn  numerous  different  languages,  cne 
for  each  system.  A  second  alternative  was  use  of  a  standard 
language;  however,  nc  language  standards  yet  exist.  A  third 
suggestion  was  the  development  of  a  system  which  could 

understand  all  languages.  Due  to  the  hign  cost  and  overhead 
involved,  this  was  also  considered  infeasible.  The  two 
remaining  viable  alternatives,  creating  a  system  whicn 
appeared  tc  use  a  standard  language  or  a  system  which 
appeared  to  be  able  to  understand  all  languages,  required 
use  cf  an  intermediary  to  convert  user  languages  to  system 
languages.  This  ' uniform izer' ,  transparent  to  the  user, 
would  receive  a  command  from  the  user  in  the  user's 

language,  check  it  for  syntax  and  semantics,  and  then 
convert  it  tc  the  appropriate  language  for  the  object 

system.  The  reverse  process  would  be  followed  for  communi¬ 
cations  from  the  object  system  to  the  user.  Thus  the  user 
would  ce  acle  tc  deal  with  various  systems  using  only  cne 
interactive  language  if  so  desired. 
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c.  Ccicutci  Aided  Desi in  Systems 

Kcre  technical  examples  cf  attempts  to  make  use  of 
computer  resources  easier  have  occurred  in  the  field  of 
computer  aided  design  (CAD)  This  is  a  growing  field,  with 
the  number  cf  CAD  systems  both  in  use  and  proposed  growing 
rapidly.  Increasing  use  of  CAD  systems  to  design  computer 
systems  in  particular  is  driven  by  the  increasing  complexity 
cf  the  systems  and  the  components  of  the  systems  being 
designed.  Several  examples  of  the  use  cf  computer  system 
CAD  systems,  with  various  tools  to  make  design  easier,  are 
the  programmer's  Workbench,  the  5-1  Project,  the  Carnegie 
teller  Ociversity  Register -Transfer  CAD  System,  and  the 
automated  design  of  control  systems. 

a.  The  Programmer's  Workbench 

The  Programmer's  Worknancn  (PWB)  ,  described  in 
References  2  and  3,  was  developed  in  conjunction  with 
computer  aided  design  systems  to  make  possible  a  software 
development  system  which  would  be  general  enough  to  be  run 
or.  difxerent  host  machines  and  to  be  used  on  different 
projects,  thus  being  both  machine  and  application  indepen¬ 
dent.  Problems  arise  in  both  computer  aided  design  and  in 
software  development  as  a  result  of  multiple  types  cf 
computers,  multiple  languages,  multiple  databases,  and 
poorly  managed  libraries.  PWB,  begun  in  1973  at  Bell  Labs, 
was  envisioned  as  a  set  of  tools  whicn  could  be  useful 
throughout  the  design  and  maintenance  of  a  computer  system. 
PWB  was  designed  to  meet  basic,  continuing  user  needs  for 
tools  tc:  generate  and  modify  manuals  ana  other  documents: 

create,  edit,  compile,  execute,  and  debug  programs;  perform 
system  generation,  installation,  and  integration  processes; 
test  the  subsystems  and  total  systems  and  analyze  test 
results;  track  system  changes  and  test  reports;  monitor 


system  performance  and  be  able  tc  simulate  and  model  system 
operations;  convert  data  files  and  load  databases  when 
needed;  and  produce  management  reports  and  statistics 
throughout  the  development  and  maintenance  of  a  system.  The 
first  i ip le mentation  of  PH  E  focused  on  the  documentation, 
programming,  and  testing  tools,  assessing  them  as  the  most 
immediately  useful  aspects  and  the  easiest  for  designers  to 
learn . 

The  initial  ?H3  thus  consisted  of  five  modules. 
The  jch-subaissicn  module  handled  job  preparation,  transmis¬ 
sion  from  workstation  to  host,  reports  on  status,  and  return 
of  output.  The  module-control  module  kept  track  cf  revi¬ 
sions  tc  programs,  assigning  identification  codes  ana  propa¬ 
gating  changes  to  other  related  modules.  A  separate  change 
module  nandled  project  wide  changes  and  trouble  and  status 
reports.  The  documentation-production  module  provided 
macros  for  formatting  documents  such  as  the  design  specifi¬ 
cations,  test  plans,  and  user  manuals.  Finally,  the  test- 
driver  module  provided  means  to  simulate  implementations  on 
various  ccntroll er/t erminal  combinations. 

Use  of  PHE  was  found  to  have  several  benefits. 
Most  obvious  was  reduced  cost.  It  was  cheaper  to  develop 
EH 3  w itn  one  set  cf  tools  than  to  work  directly  cn  each 
different  host  computer  an  the  design  process.  The  uniform 
programming  environment  produced  oy  the  ?W3  tools  made 
training,  documentation,  programming  standardization,  and 
programmer  retraining  (fcr  a  new  project  or  new  machine) 
easier.  Additionally,  it  reduced  the  conflicts  arising 
during  acquisition  of  new  machines  as  a  result  cf  the 
differences  between  ideal  online  machines  and  ideal  software 
development  machines  ty  providing  an  environment  independent 
cf  the  machine  involved.  Future  work  on  PWB  was  expected  in 
areas  which  would  even  further  increase  user  convenience, 
such  as  using  a  standard  programming  language  which  ?W3 
weald  then  convert  tc  code  appropriate  to  the  host  machine. 

1 1 


t.  Ths  S-1  Project 

la  e  s-1  Project,  using  the  Structured 
Computer-Aided  Logic  Design  System  (SCALD)  ,  is  described  m 
fieferences  4  and  5.  S-1  was  an  attempt  to  use  graphics  to 
make  the  designer's  job  in  the  computer  aided  design  of 
large  digital  systems  easier.  SCALD  was  developed  to  reduce 
required  design  time  "by  allowing  the  designer  to  expres  his 
design  or.  the  same  level  that  he  thinks  about  it"  [Ref.  4: 
p.  271].  SCALD,  written  m  Pascal,  uses  the  Stanford 
University  Drawing  System  (SUDS)  for  designer  input  tc  the 
system.  Designers  input  a  high  level  logical  design  drawing 
through  a  giapnics  terminal.  A  'macro  expander',  working 
with  a  pictorial  library  of  hardware  components,  repeatedly 
reduces  the  logical  design  to  various  stages  of  physical 
design,  until  data  fcr  the  actual  implementation  and  manu¬ 
facture  is  produced.  SCALD  was  used  at  Lawrence  Liv armors 
Laboratory  to  design  the  S-1,  a  550-chip  2CL-10K  prccessor; 
however  it  has  not  teen  applied  to  general  computer  system 
design. 

c.  The  Carnegie-Mellen  University  Project 

The  Car negie-fle lion  University  Register-Transfer 
Computer  Aided  Design  (C3(J  RT-CAD)  System,  described  in 
References  6,  7,  a,  9  and  10,  was  developed  as  a  system 

which  could  design  computer  systems  from  inputs  containing 
functional  descriptions  rather  than  structural  aspects. 
Designer  input  tc  the  system  includes  a  behavioral  descrip¬ 
tion  cf  the  system  and  the  user's  optimization  criteria  (for 
example,  time  or  cost)  .  Also  included  is  a  database  of 
available  hardware  components  which  can  be  permanently 
stored  and  updated,  rather  than  reentered  each  time.  The 
system  then  transforms  this  input  into  a  form  readable  by 
tna  'allocator',  and  attempts  to  construct  the  desired 


system  frca  components  available  in  the  hardware  library, 
within  the  constraints  given  by  the  designer.  The  CMU 
ET-CAD  system  has  been  used  in  system  simulation,  design 
logic  verification,  and  actual  hardware  design.  It  can  be 
adapted  tc  different  design  styles,  such  as  centralized, 
distributed,  or  pipeline  systems. 

d.  Automated  Design  of  Control  Systems 

Attempts  have  also  been  made  to  use  computer 
aided  design  in  the  design  cf  control  systems,  again  begin¬ 
ning  with  fucticnal  descriptions.  One  model  for  the  automa¬ 
tion  cf  real-time  controller  design,  described  in  References 
11  and  12,  uses  functional  level  input  in  terms  of  pairs  of 
contingencies  and  tasks,  a  function  to  determine  when  a 
contingency  exists,  and  a  procedure  to  carry  cut  the 
resulting  required  task.  Also  included  are  environmental 
data  (controller  input  and  output)  ,  design  criteria,  and 
designer  and  project  information.  Data  entered  by  the 
designer  is  converted  into  a  'primitive  list*  description, 
and  then  compared  with  possible  realizations  in  a  hardware 
description  library  until  a  match  is  found.  Implementation 
of  the  model  includes  the  action  linking  the  primitive  list 
tc  the  hardware  realizations  and  the  development  cf  a 
acnitcr  tc  sequence  the  contingency  test  and  task  execution 
pairs . 

Another  model,  LOGE-MI3  [8ef.  13],  uses  picto¬ 
rial  flew  diagrams  as  the  means  to  input  basic  design  infor¬ 
mation,  since  flow  diagrams  are  a  common  design  format. 
Because  the  design  system  is  limited  to  control  applica¬ 
tions,  it  is  possible  to  establisa  a  strict  problem  specifi¬ 
cation  format  using  flow  diagram  symbols.  The  flow  diagram 
is  then  converted  into  an  intermediate  language  and  general 
optimizations  are  done.  In  the  final  step,  the  intermediate 
language  is  combined  with  an  interpreter  for  a  specific 


microcomputer  to  oroauce  the  design  output.  This  two  step 
transformation  mcKes  it  easier  to  adapt  the  design  system  to 
new  microcomputers,  since  the  design  input  can  remain  the 
same  and  only  the  interpreter  must  be  rewritten.  Another 
advantage  of  this  system  is  in  having  the  system,  rather 
than  the  designer,  write  the  design  software,  thus  reducing 
the  opportunity  for  errors. 

C.  TEE  COBBENT  SITUATION  IN  COHPUTEB  AIDED  DESIGN 

In  discussing  the  CMU  BT-CAD  system,  Baraacci  [Ref.  9] 
pointed  cut  that  designers  should  not  have  to  do  "repeti¬ 
tive,  time  consuming  tasks"  such  as  generating  detailed 
design  information,  monitoring  changes  in  design  documents, 
checking  systems  for  electrical,  logical,  or  physical  compa¬ 
tibility,  or  developing  manufacturing  information.  Rather, 
as  technology  evolves,  with  primitive  components  becoming 
more  complex  and  the  rate  at  which  new  components  are  intro¬ 
duced  increasing,  designers  must  be  able  to  design  at  a 
higher  level,  and  must  be  able  to  design  faster.  Ross,  in 
commenting  on  computer  aided  design  systems  in  general,  and 
means  for  design  of  control  systems  specifically,  pointed 
cut  that  systems  had  to  be  attractive  to  be  used,  and  should 
"perform  a  helpful  part  of  the  design  task,  must  present  the 
results  in  a  useful  format,  and  must  be  easy  to  use" 
[Ref.  11;  p.87]. 

However,  despite  tne  good  intentions,  a  gap  exists 
between  the  designer  of  a  CAD  system,  with  his  or  her 
assumptions  and  expectations  regarding  the  user  and  the 
user's  needs,  and  the  actual  user  of  the  system.  As 
discussed  in  References  14,  15,  16  and  17,  CAD  systems  exist 
to  aid  the  designer  in  the  design  process,  not  to  automate 
it  completely.  CAD  system  users  are  not  computer  program¬ 
mers,  hence  their  input  should  be  in  something  close  to 


tneir  design  language,  not  in  a  programming  language.  In 
addition,  in  appears  than  each  individual  system  is  designed 
for  a  unique  need,  and  with  a  unique  language,  thus  limiting 
the  user's  flexibility.  The  tools  which  thus  result  from 
these  false  assumptions  require  users  to  think  in  a  new  way, 
cr  learn  a  new  language,  and  are  more  of  a  hindrance  than  a 
help.  Dsers  are  expected  to  be  net  just  engineers  or  desig¬ 
ners  in  a  particular  field,  but  also  computer  programmers 
with  tine  tc  learn  a  special  purpose  language.  As  with 
bibliographic  query  languages  and  procedures,  a  need  exists 
for  seme  sert  cf  adaptability  in  computer  aided  design 
systems,  and  the  languages  which  they  use. 

0.  THIS  IBCJECT 

In  an  effective  design  environment,  the  designer  can 
focus  cn  design  rather  than  spending  time  on  implementation 
details  and  repetition  of  tedious  tasks.  The  purpose  of 
this  project  was  to  create  a  design  environment  in  which, 
with  a  minimum  cf  training  in  areas  outside  those  actually 
required  fer  design,  a  user  would  oe  able  to  use  the  avai¬ 
lable  tools  to  enter  required  data.  Emphasis  was  placed  on 
designing  a  workstation  which  operates  in  such  a  manner  that 
the  user  is  not  required  to  learn  an  additional  programming 
language . 

The  model  developed  for  automated  control  system  design 
served  as  a  vehicle  for  this  project.  Tools  were  still 
needed  in  this  model  to  create  a  workstation  for  design  data 
input  and  convert  that  input  to  the  primitive  list  format. 
This  project  focused  on  the  man-machine  interface  of  the 
model,  the  means  to  input  the  design  data. 

The  goal  in  designing  and  implementing  this  design  envi¬ 
ronment  was  to  build  a  workstation  which  removes  the  need 
for  the  designer  tc  learn  a  specific  language  with  which  to 
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entsr  the  data.  Additionally,  the  system  should  present  a 
user-friendly  approach  to  the  interface.  Finally,  the 
system  should  produce  an  output  of  the  data  entered  in  a 
user  readable  format  which  is  ready  to  be  converted  to  the 
primitive  list  format. 

Chapter  Two  will  summarize  the  development  of  hardware 
description  languages  and  the  human  factors  which  must  be 
considered  in  developing  a  computer  aided  design  system. 
Chapter  Three  will  examine  the  implementation  decisions  made 
regarding  design  of  the  system.  Chapter  Four  discussses  the 
implementation  of  the  system,  and  Chapter  Five  considers  the 
conclusions  which  can  be  drawn  and  recommendations  made  for 
future  work. 


II.  BACKGROUND 


A.  H  ARCS ABZ  DESIGN  IANGOAGES 

&  critical  requirement  for  a  computer  design  system  is  a 
hardware  design/description  language.  Over  the  past  15-20 
years,  computer  hardware  description  languages  (CHDLs)  have 
gone  from  fceing  useful  to  being  a  necessity  as  technology 
and  design  components  have  become  more  complex.  Ecth  Chu 
[Ref.  18:  p.  19]  and  Van  Cleemput  [Ref.  19:  pp.  554,  559  ] 
see  computer  hardware  description  languages  as  neing  able  to 
provide : 

accurate  ccmmunicatxon  among  designers  and  engineers; 
precise,  concise,  and  convenient  docmentaticn ; 
a  means  fcr  system  simulation  and  verification;  and 
a  means  tc  automate  system  design  and  realization. 

Hardware  design  progresses  through  a  hierarchy  of  stages, 
from  system  level  through  register-transfer  and  gate  levels 
to  circuit  level  and  logic  detail.  Design  can  be  approached 
from  either  a  top-down  or  bottom-up  perspective  [Ref.  20:  p. 
377],  As  a  result  of  tais,  seme  CHDLs  deal  with  only  one  or 
two  levels  in  the  hierarchy,  while  others  attempt  to  deal 
with  all  levels  in  the  process.  Additionally,  the  earliest 
CHDLs  described  systems  on  only  the  most  primitive  level, 
and  dealt  directly  with  implementation.  As  systems  became 
more  complex,  higher  level  description  languages  developed, 
much  as  higher  level  programming  languages  have  been  formu¬ 
lated  in  the  past  decade. 
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1 .  CEL 


CEL,  described  in  References  21  and  22,  was  intro¬ 
duced  in  1965  as  "an  Algol- like  computer  design  languace"  to 
provide  a  language  which  could  be  used  as  a  standard  design 
language,  making  possible  both  communication  among  designers 
and  well-documented  designs.  Additionally,  it  was  expected 
that  CEL  could  be  used  to  test  and  debug  designs,  simulate 
and  evaluate  performance,  and  make  possible  automated  design 
and  design  cf  more  complex  machines.  CDL  met  the  basic 
requirements  set  forth  by  Chu  that  it  be  like  natural 
language,  concise  and  precise,  translatable  into  boolean 
equations,  able  to  be  modified  as  the  technology  it  was 
describing  changed,  and  be  able  to  represent  and  manipulate 
data,  control,  and  timing  signals  in  binary  format. 

CEL  descriptions,  'sequences'  (which  are  actually 
micrcpr cgrams)  ,  are  used  to  define  the  implementation  cf  an 
algorithm,  and  follow  a  standard  format.  First  is  a  name 
for  the  sequence,  followed  by  declarations  of  registers, 
subr egisters,  memory,  terminals,  and  operations.  Statements 
are  the  final  component  of  the  description.  Each  statement 
is  labeled,  either  with  a  boolean  label  or  a  name  if  it  is 
the  first  lire  in  one  of  the  declared  operations.  Compound 
statements  share  a  label  and  are  expected  to  be  executed 
within  cne  clock  period.  Statements  are  not  executed  unless 
their  bcclean  labels  are  true;  this  provides  the  control 
structure.  Thus,  as  shown  in  Reference  23,  a  typical 
segment  of  a  sequence  in  CDL  would  be  written: 

/f etch*p3/  IR  <-  MDfi, 

boolean  label  statement 
While  CDL  makes  it  possible  to  name  basic  circuits, 
registers,  inputs,  and  outputs,  and  write  conventional 
arithmetic  and  logical  operations,  it  still  remains  a  fairly 
low  level  description  language.  It  retains  the  ability  to 
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describe  tit  level  actions  such  as  a  shift, 
difficult  tc  use  at  higher  than  a  register- tzansf er  level. 
However,  an  attempt  has  been  made  to  extend  CDL  into  MIL , 
Hrcrcccmputer  Design  Language  £Hef.  24],  which  will  make 
possible  the  hierarchical  description  of  a  system  through 
use  cf  level  numbers.  MDL  can  be  used  with  SDL-1,  Software 
Design  Language  1,  tc  show  hardware  and  software  interaction 
at  a  given  level  of  a  system. 

2.  AHPL 

A  Hardware  Programming  Language  (AHPL) ,  discussed  in 
Seferences  25,  26,  27,  28  and  29,  was  developed  as  an 

attempt  to  design  a  functional  level,  rather  than  a 
register-transfer  level  language.  AHPL  was  based  on  the 
APL  programming  language,  with  APL's  vector  notation  making 
it  possible  to  mere  easily  deal  with  entire  registers  rather 
than  individual  flip-flops,  while  at  the  same  time  being 
able  tc  identify  individual  bits  or  segments  of  registers. 
AHPL  attempted  tc  partition  a  system  into  control  sequences 
and  data  registers,  and  provide  an  alternative  to  circuit 
diagrams  and  state  tables  which  became  more  involved  as 
systevs  became  mere  complex. 

The  standard  format  of  AHPL  consists  of  a  aeclar- 
aricn  cf  inputs,  outputs,  and  registers,  followed  by  state¬ 
ments.  Bather  than  CDL's  boolean  labels,  statement  lines 
are  labeled  wita  sequential  numbers  to  correspond  to  the 
rows  in  an  equivalent  state  table.  All  data  transfers  on 
cne  line  are  expected  to  occur  simultaneously.  Statement 
lines  are  executed  sequentially,  unless  followed  by  a  state¬ 
ment  tc  branch  to  a  different  lrne.  This  produces  a  'con¬ 
trol  sequence*  of  transfers  and  branches.  As  a  final  step, 
names  can  be  assigned  to  transfers  to  produce  a  "combina¬ 
tional  logic  subroutine"  [Bef.  25],  with  the  name  used 
instead  cf  the  detailed  notation.  However,  this  is  the 
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closest  AHEL  comes  to  being  a  functional  rather  than 
register-transfer  language. 


Digital  System  Design  language  (DDL)  ,  described  in 
Beferences  30,  3  1,  32  and  33,  was  designed  to  fill  seme  of 
the  design  language  needs  not  met  by  languages  such  as  CDL 
and  AHEL.  It  was  developed  to  meet  several  goals,  among 
them  that  it  be  useful  at  all  levels  of  the  design  process, 
from  block  structured  architecture  to  gate  level  activity, 
that  it  net  be  limited  in  application  to  a  specific  hardware 
technology,  that  it  be  able  to  be  used  as  a  source  language 
in  automated  design  in  the  future,  and  that  it  provide  docu¬ 
mentation  which  matched  the  actual  system  organization. 

The  DDL  system  model  consists  of  one  or  more  auto¬ 
mata  (finite  state  machines)  which  control  data  facilities. 
Data  facilities  can  be  either  private,  if  controlled  by  one 
automaton,  cr  public,  if  controlled  by  more  than  one.  Bach 
automaton  can  be  divided  into  segments.  Repeated  transfor¬ 
mations  of  this  initial  system  description,  or  a  design 
initiated  at  any  intermediate  level,  will  ultimately  result 
in  a  final  system  description  consisting  of  lcgic  equations. 
Cietmeyer  describes  CDL  as  "not  well  suited  for  describing 
extremely  abstract  models. . . . [ or  ]  for  presenting  fabrication 
and  technological  details.  It  ns  intended  to  bridge  the 
gap"  [Bef.  32:  p.  38].  Later  revisions  of  DDL  add  a  module 
construct  tc  maintain  modularity  in  each  transformation 
output  and  thus  make  a  top-down  design  aethcdciogy  using  DDL 
more  feasible. 

4.  SEL 


Alsc  based  on  the  concept  that  hardware  design  gees 
through  stages  from  higher  to  lower  level,  SDL  [Bef.  20]  was 
developed  with  the  objective  of  providing  an  "accurate 


zepr 6S6rtati.cn  cf  structural  information  useful  cv.-:  all 
levels  of  the  design  process'1  [  Hef •  20:  p.  378],  with  a 
designer  able  to  use  SDL  to  map  from  higher  level  hardware 
primitives  tc  lower  level  implementations. 

A  structural  information  description  in  SDL  consists 
of  a  name,  external  connections  (input/output)  ,  component 
types,  and  interconnections  among  the  components. 
Additionally,  each  description  must  have  a  purpose  or 
possible  use  statement,  and  an  indication  or  which  level  of 
the  design  hierarchy  (system,  r  agister- transf  er)  the 
description  refers  tc.  Level  and  purpose  statements  are 
related,  and  each  purpose  and  level  pair  will  use  a  library 
cf  resources  which  are  available  at  the  next  lower  level  in 
the  design  hierarchy. 

5.  "S" 

Another  language  which  uses  an  approach  similar  tc 
that  cf  SEL  is  '* S"  [  Bef.  34  ].  Design  using  "S"  begins  with 
a  natural  language  description,  since  this  xs  where  a 
designer  actually  begins  the  design  process.  Also,  this  is 
easier  tc  understand  than  some  of  the  formal  design  and 

description  languages.  "S"  makes  it  possible  to  process  the 

description  and  add  levels  of  increasing  syntactic  and 
semantic  restrictions  until  all  ambiguities  have  been 

removed.  At  this  point  the  computer  can  examine  implementa¬ 

tion  possibilities.  Basic  structure  of  a  description  in  "S'1 
includes  a  declaration  section,  with  input/output  variables 
and  their  types,  conditions  (*  inhibitors ' )  cf  the  system, 
and  a  section  for  process  description. 

6. 

Instruction  Set  Frocessor  (IS?)  notation,  described 
in  References  9,  35,  36,  37,  38  and  39,  and  later  modifica¬ 
tions  I3EI  and  ISPS,  were  developed  as  part  of  a  set  of 
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lanyuag^s  intended  tc  be  able  10  provide  a  description  a 
computer  from  the  tep  of  the  hierarchy,  the  system  level, 
down  through  the  lower  levels.  A  fifth  level,  the  program¬ 
ming  level,  unique  to  computers,  was  added  to  the  tradi¬ 
tional  design  hierarchy.  This  programming  level  is  located 
between  the  system  level  and  the  r agister- transfer  level. 
ISP  is  used  to  describe  this  level,  that  of  the  machine's 
instruction  interpretation  cycle,  where  memory  is  accessed 
and  operations  are  performed,  in  terms  of  tns  next  lower 
level,  the  register- transfe r  level.  IS?  is  thus  the  inter¬ 
face  between  the  programming  level  and  the  register-transfer 
level.  Symbolically  a  register-transfer  language,  but  mere 
general  than  most,  it  describes  what  occurs  at  the 
register-transfer  level,  but  not  how  it  occurs.  ISP 
excludes  timing  data  and  other  details  of  that  sort. 

Ir  format,  ISP  resembles  other  register-transfer 
languages.  Declarations  include  memory,  processor  and 
registers,  any  external  connections,  and  data  types  avai¬ 
lable.  The  remainder  of  the  description  is  devoted  tc  the 
instruction  interpreter,  describing  the  steps  in  the  fetch- 
execute  cycle  and  each  instruction  in  the  instruction  set. 

ISP  has  teen  used  extensively  in  the  Carnegie-Mellon 
University  FT-CAD  system  described  in  Chapter  One  as  a  tool 
tc  describe  digital  systems,  simulate  and  emulate  systems, 
synthesize  hardware  and  software  descriptions,  and  verify 
designs.  This  has  revealed  some  limitations  in  ISP 
[Ref.  38].  Cne  is  a  lack  of  a  formal  semantic  definition  of 
the  language,  which  has  led  to  variations  m  the  format  of 
descriptions  in  ISP,  and  the  use  or  ISP  to  describe  only 
part  cf  a  system.  Another  limitation  is  the  lack  of  a  means 
to  handle  concurrency,  timing  data,  and  interconnected 
processors  in  ISP. 


7 .  CCNLAN 

As  the  number  of  computer  hardware  design  languages 
multiplied,  it  was  decided  that  the  need  existed  for  seme 
common  fcase  from  which  to  develop  future  languages.  As  a 
result  of  this  decision,  a  working  group  of  the  designers  of 
AHPL,  DDL,  AND  ISP,  among  ethers,  was  formed  in  the  middle 
1970s  to  develop  CONLAN  (CONsensus  LANguage)  .  Discussed  in 
References  40,  41,  42,  43  and  44,  CONLAN  was  intended  to 

provide  for  greater  acceptance  of  hardware  description 
languages  through  providing: 

a  ccmscn  formal  syntactic  and  semantic  base  for  ail 
levels  and  aspects  cf  hardware  and  firmware  description, 
in  carticular  for  descriptions  of  system  structure  ana 
behavior. . . 

a  means  for  the  derivation  of  user  languages  from  this 
cc mien  fca se. . . 

(■support  to]  CAD  tools  for  documentation,  certification, 
design  space  exploration,  [and]  synthesis . 

[Ref.  40.  p.  210]. 

It  was  expected  that  languages  developed  from  Base  CCNLAN 
would  be  designed  for  a  specific  set  of  tasks  ana  have  a 
limited  scope,  oe  easy  to  learn  and  simple  to  use,  and  have 
a  clear  semantic  relationship  to  other  languages  also  devel¬ 
oped  frci  Base  CONLAN. 

Ease  CONLAN  is  defined  ty  three  items,  a  set  of 
object  types  and  operations,  syntax,  and  a  computation 
model.  It  is  defined  with  Primitive  Set  CONLAN,  a  language 
used  only  for  defining  other  languages  derived  in  CONLAN. 
Cnee  a  language  has  teen  derived  from  Base  CCNLAN,  its  use 
as  a  computer  hardward  design  language  follows  a  standard¬ 
ized  format.  Bach  description  serves  as  a  module  by  itself. 


A  description 

is  begun 

with  a  name. 

followed  by 

a  listing  of 

assertions  cf 

s  ta  t  i  c 

ccnd itions 

and  dynamic 

constraints. 

Then  the  items 

from  an 

external  segment  library. 

if  any,  are 
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listed,  and  internal  and  external  variables  are  declared. 
Finally,  the  behavior  of  the  model  is  described,  using 
activities  and  functions,  with  'end*  indicating  the  end  of 
the  description. 

8.  CSDl 

Sihile  there  have  been  numerous  register-transfer 
languages  developed,  and  attempts  to  develop  languages  which 
can  trace  design  through  the  entire  design  hierarchy,  there 
have  been  few  languages  written  which  actually  define  a 
system  in  terms  of  its  functions  rather  than  its  structure. 
Additionally,  most  computer  Hardware  design  languages 
describe  operations  which  are  carried  cut  in  a  definite 
sequence,  rather  than  concurrently  (programming  languages 
have  also  followed  this  approach,  with  Ada  being  the  first 
major  language  in  which  concurrency  was  included  in  the 
original  design)  .  An  attempt  was  made  to  meet  both  of  these 
requirements  in  the  development  of  CSDL,  Control  System 
Design  Language  £Ref.  45],  utilized  in  the  control  system 
design  automation  project  discussed  in  Chapter  One.  The 
goal  cf  CSDL  was  tc  simplify  problem  specification  and 
provide  a  means  to  automate  hardware  selection  and  software 
production  in  control  system  design.  One  way  to  accomplish 
this  was  to  develop  a  language  in  which  the  •  designer  had 
only  tc  provide  the  behavior  of  the  control  system,  what  it 
did  given  certain  inputs  and  outputs,  rather  than  hew  it 
actually  did  it,  or  what  hardware  components  were  used. 

CSDL  descriptions  have  four  major  sections.  First, 
as  an  aid  to  good  documentation,  is  an  identification 
section  with  the  designer's  name,  the  date,  and  the  design's 
title.  This  is  followed  by  the  environment,  the  input  and 
output  variables  to  and  from  the  controller.  Third  are  the 
contingency  lists,  the  key  to  what  makes  this  a  design  for 
multiple  concurrent  activities.  Contingency/task  pairs 
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indicate  the  relationships  between  a  contingency,  a  cask 
which  must  be  carried  out  when  that  contingency  occurs,  and 
ongoing  physical  time.  The  final  section  in  CSDL  is  the 
procedural  cne,  with  functions  wnich  return  boolean  values 
defining  contingencies  and  sampling  the  environment,  and 
tasks  performing  actions  on  elements  in  the  environment  and 
making  changes  in  it. 

While  BNF  notation  for  CSDL  has  been  written,  and 
CSDL  has  teen  used  as  documentation  for  control  system 
design  automatics  research  projects,  a  compiler  has  not  yet 
been  written  for  it  and  thus  it  has  not  yet  been  used  as 
source  code  input  for  automated  design. 


B.  HAN- MACHINE  INTERFACE 

1 .  Dialogue 

A  second  critical  need  in  a  computer  aided  design 
system  is  for  a  design  environment,  similar  to  a  programming 
environment.  The  important  consider aticn  in  this  is  net  the 
designer  or  the  computer  individually,  but  their  interface, 
since 


human  factors  eng 
designing  machines 
t  n  a  t  thsy  match 
[3ef.  46:  p.  8]. 


ineerin g. . . is  concerned  with  ways  of 
,  operations,  and  work  environments  sc 
human  capabilities  and  limitations 


In  an  interactive  computer  system,  the  need  is  fer  system 
ccmmpcnsnts  with  which  tne  user  will  be 


able  to 
that  he 
medium  in 


engage  in  a  man-comput 
is  essentially  unaware 
which  the  dialogue  is 


sr  dialogue  so  designed 
of  the  computer  cr  the 
conducted  [aef.  47:  p. 


Dialogue  is  defined  as  "nonprogramming  commur.icat ion 
with  a  terminal"  [Ref.  48:  p.  53],  and  is  what  lakes  a 
computer  system  interactive.  Responses  from  the  system  in  a 
dialogue  can  be  placed  in  ere  or  three  categories,  these 
which  never  change,  these  which  change  periodically,  and 
those  which  change  cn  a  real-time  basis  as  the  dialogue  is 
conducted.  Dialogues  in  the  first  two  categories  are  gener¬ 
ally  written  by  the  programmer  and  stored  in  memory.  While 
real-time  dialogue  can  be  close  to  natural  language,  it 
requires  a  great  deal  ox  software,  including  both  a  dialogue 
translator  cr  processor  and  one  or  more  dialogue  files,  as 
implemented  in  systems  described  in  References  49  and  50. 

Dialogue  style  can  be  one  of  four  types,  based  on 
two  independent  characteristics,  whether  the  user  of  the 
system  guides  the  the  interchange,  and  wnether  the  user  is 
limrted  to  given  choices  in  reply  or  can  make  a  free 
response  [Ref.  51],  At  the  ends  of  the  continuum,  dialogues 
which  tbe  system  guides,  with  limited  cncice  response,  are 
faster,  with  fewer  entries  required  for  routine  actions. 
User  guided  free  response  dialogues  provide  maximum  flexi¬ 
bility  (and  maximum  opportunity  for  error)  for  experienced 
users.  Martin  [Ref.  48  3,  i-  what  has  become  a  classic  in 
interactive  system  design,  categorizes  23  techniques  for 
dialogue  design,  with  factors  which  can  help  determine  the 
most  effective  type  of  dialogue  for  a  specific  task  and 
environment. 

Smith  [Ref.  52]  provides  the  two  essential  proper¬ 
ties  cf  the  resulting  system.  It  should  be  effective,  able 
to  accomplish  something  significant  in  a  'reasonable'  amount 
cf  time,  and  it  should  be  simple,  although  its  simplicity 
will  be  inversely  proportional  to  the  complexity  cf  the 
tasks  it  performs.  In  doing  this,  the  system  should  be 
self-explanatory,  self-help ing,  easy  to  use,  able  to  antici¬ 
pate  the  user's  actions,  and  able  to  adjust  to  the  skill 
level  of  the  user. 


fieference  53  defines  three  components  of  a  user 
interface:  the  user's  conceptual  model  of  tae  actions  going 
on,  the  command  language  used  by  the  user  to  communicate 
witn  the  system,  and  the  information  display  used  by  the 
system  to  communicate  with  the  user.  Increasing  the  signi¬ 
ficance  of  the  graphics  factor,  and  with  seme  reorganiza¬ 
tion,  Newman  and  S  picul  list  four  components  of  the  user 
interface : 

User  Model  -  the  mcdsl  which  the  user  has  of  the  infor¬ 
mation  involved  and  hew  it  is  being  manipulated  and 
processed.  This  component  underlies  the  other  three. 

Command  Language  -  how  the  user  operates  on  the  informa¬ 
tion  anc  the  model. 

Feedback  -  how  the  system  provides  the  user  with  infor¬ 
mation  and  assistance  in  running  the  system  and  using 
the  model. 

Information  Display  -  the  screen  display  of  the  state  of 
the  model  ana  the  information  being  manipulated.  This 
can  be  used  to  confirm  that  the  user's  perception 
matches  the  state  cf  the  system  [fief.  54:  pp.  445-448]. 

Cf  critical  importance  is  the  fact  that  the  user's 
model  is  a  mental  image,  not  something  in  writing.  It  is 
something  with  which  the  user  must  be  comfortable,  and  be 
able  to  become  familiar.  Thus,  to  make  the  system  easier  to 
learn  and,  at  least  intuitively,  easier  to  understand,  the 
system  should  use  concepts  and  language  familiar  to  the 

US  r  • 

2.  The  User  and  Cser  Psychology 

The  user,  and  the  user's  psychology,  are  seme  of  the 
first  factors  which  must  be  considered  in  designing  an 
interactive  system  from  wnich  the  user  will  be  able  to 
develop  a  useful  and  appropriate  model. 

Eascn  and  Damodaran  [fief.  55]  consider  as  signifi¬ 
cant  factors  m  analyzing  computer  interfaces:  jcb  related 

user  attributes  such  as  the  training  provided  and  the 
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relaticnshi p  between  the  user's  total  joo  and  the  computer 
systeis;  user  requirements  of  the  system,  including  psycholo¬ 
gical  needs;  variables  related  to  the  task;  such  as  structure 
and  information  handling;  and  individual  user  personality 
characteristics.  Martin  [ Bef .  48]  has  determined  six  basic 
criteria  with  which  to  categorize  terminal  operators. 
First,  they  can  he  either  dedicated  or  casual,  working  cons¬ 
tantly  at  the  terminal  or  only  occasionally.  The  second 
consideration  is  their  level  of  programming  skill.  Thirl  is 
their  intelligence  level,  specifically  their  short  term 
memory  span  and  ability  to  think  logically.  Fourth  is  their 
level  of  training  and  skill  with  regard  tc  the  terminal  they 
are  using.  The  fifth  factor  is  whether  they  are  active 
operators,  taking  tie  initiative  in  the  task,  or  passive 
ones,  following  the  direction  of  the  computer.  Finally,  are 
there  intermediaries  between  the  user  and  the  system,  cr  is 
the  user  able  to  deal  directly  with  it?  Martin  gives  addi¬ 
tional  consideration  to  the  case  of  the  totally  untrained 
operator . 

Five  potential  blocks  to  maximizing  user  involvement 
with  an  interactive  system  exist  [Bef.  56],  Users  can 
become  cored  with  a  system  if  pacing  of  screens  is  tcc  slow 
cr  response  time  allowed  is  too  great.  Unexpectedly  long 
delays  without  system  response  can  lead  to  user  panic  due  to 
fear  that  there  is  somethin  wrong  in  either  the  system  or 
the  program  being  executed.  Frustration  can  result  from 
being  unable  to  easily,  effectively,  and  efficiently  commu¬ 
nicate  with  the  system  and  safely  recover  from  unwanted  cr 
unexpected  actions.  Inability  by  the  user  to  formulate  an 
appropriate  user's  model,  caused  by  either  excessive  detail 
cr  lack  of  structure  in  the  system,  can  lead  to  confusion  on 
the  part  of  the  user.  Finally,  discomfort  can  result  from 
shortcomings  in  the  physical  environment,  such  as  pcor 
lighting  cr  lack  of  sufficient  work  space. 


Belated  to  sens  of  these  potential  problem  a reas  are 
seme  basic  human  psychological  characteristics.  First,  as 
noted  by  G.  A.  Miller  [Ref.  57],  the  factor  seven,  plus  or 
minus  twe,  is  a  recurring  item  in  human  short  term  memory 
research.  Whether  data  is  considered  as  individual  items, 
cr  recoded  into  'chunks'  as,  for  example,  letters  into 
words,  cr  individual  numbers  into  a  telephone  number,  humans 
are  generally  able  tc  recall  only  seven  chunks  cr  make  accu¬ 
rate  decisions  among  nc  more  than  seven  choices.  Exceeding 
seven  (plus  or  minus  two)  units  of  data  in  providing  infor¬ 
mation  can  lead  to  information  overload  on  the  part  of  the 
user . 

While  Miller  has  shown  that  people  can  handle  mere 
data  if  they  can  greup  it  into  chunks,  human  ability  tc 
handle  pictorial  information  can  also  be  a  factor  in 
increasing  the  amount  of  information  a  user  can  handle  when 
working  with  an  interactive  system.  Saber  and  Wilkinson 
[Ref.  58]  point  cut  two  principles  m  human  visual  percep¬ 
tion:  the  human  vision  system  is  designed  tc  capture  the 

total  situation  perceived,  and  the  system  will  try  tc  inter¬ 
pret  ail  components  as  part  of  the  scene.  Thus,  visual 
displays  can  be  used  tc  convey  not  just  oits  of  information, 
but  also  the  structure  of  the  information,  to  the  user, 
with  this  approach,  there  will  be  le'ss  need  for  the  observer 
to  consciously  interpret  the  organization  of  the  information 
presented,  cr  try  tc  group  its  individual  compcnents  into 
chunks. 

This  human  need  to  organize  information  also  has  an 
effect  cn  how  people  keep  track  of  their  activities 
[Ref.  59].  Just  as  people  organize  bits  of  information  into 
chunks,  they  organize  their  activities  into  'clumps', 
sequences  cf  steps  which  lead  them  toward  a  goal  or  accom¬ 
plishment  of  a  task.  Completion  of  one  of  these  clumps  of 
actions  leads  to  'closure',  indication  that  a  jefc,  or 
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subjcb,  has  bean  finished  and  can  he  crossed  off  one’s 
mental  ’tc  do'  list.  When  working  in  an  interactive  system, 
whether  with  other  humans  or  machines,  one  expects  net  or.ly 
an  internal  reeling  cr  closure  upon  completing  a  clump  of 
actions,  tut  also  a  feedback  response  from  the  other  part  of 
tne  system,  either  during  or  at  the  end  of  the  activity. 
Depending  on  the  specific  type  of  action,  this  response  is 
expected  within  a  certain,  limited,  amount  of  time.  Delay 
can  lead  tc  frustration  and  lack  of  continuity  of  thought, 
while  closure  and  response  brings  the  opportunity  tc  clear 
short  term  memory  and  move  on  to  a  new  thought.  Eesponse 
time  delays  are  mere  acceptable  once  closure  has  been 
reached  than  they  are  before,  since  short  term  memory  can 
store  data,  such  as  a  phone  number,  for  only  a  limited 
amount  of  time.  is  a  general  rule,  delays  over  two  seconds 
are  acceptable  once  closure  has  been  reached  (waiting  for 
the  ringing  after  dialing  a  telephone  number),  but  not 
before  (waiting  for  a  dialtone  so  a  telephone  number  just 
looked  up  can  be  dialed)  .  The  decrease  in  efficiency 
resulting  from  response  time  delays  is  net  a  linear  rela¬ 
tionship.  Father,  a  delay  produces  a  sudden  drop  in  user 
efficiency,  followed  by  a  leveling  off  for  a  period,  what 
R.  E.  Miller  refers  to  as  "psychological  step-down 
discontinuities. " 

is  a  guideline  to  dealing  with  the  characteristics 
of  designers  using  CAD  systems,  Spence  and  Apperley 
[Hef.  60]  provide  a  checklist  of  items  to  be  considered, 
based  in  part  on  the  proceeding  psychological  factors: 

Short  term  memory  is  limited;  an  interruption  will  lead 
to  forgetting. 

Psychologies  1  clostre  is  needed:  provide  an  indication 

to  the  user  that  a  task  is  complete. 

Consider  computer  response  time;  allow  time  for  the  user 
to  see  the  result  cf  an  action. 

Respond  tc  control  actions;  predict anility  is  needed. 


30 


Consider  human  pattern  recognition  skills;  make  use  cf 
them  m  data  interpretation. 

Use  words  appropriate  to  the  task;  users  need  familiar 
terminology. 

Martin  [Bef.  48]  proposes  that,  when  designing  a 
system,  it  be  considered  on  three  levels;  functional  (how 
to  use  both  human  and  machine  capabilities  most  effec¬ 
tively),  procedural  (how  to  organize  the  system),  and 
syntactical  (how  to  handle  communcaticns  between  the  user 
and  the  system).  Ginsburg,  guoted  in  Reference  61,  pcints 
cut  the  critical  importance  of  the  user,  and  the  user's 
perspective,  in  the  ef fecti vsness  of  an  interactive  system: 

Nothing  can  contribute  more  to  satisfactory  system 
performance  than  the  conviction  on  tne  part  of  the 
terminal  ooeratcrs  that  they  are  in  control  of  the 
system  and  hot  the  system  in  control  of  them.  Squally, 
nothing  can  be  mere  damaging  to  satisfactory  system 
operation,  regardless  of  hew  well  other  aspects  cf  the 
implementation  have  been  handled,  than  the  operator's 
conviction  that  the  terminal  and  thus  the  system  are  in 
control,  have  'a  mind  cf  their  own,'  or  are  tuggita 
against  rather  than  observing  the  operator's  wisnesl 
£p.  12  j 

This  then  leads  to  consideration  of  the  remaining 
three  components  of  the  interface;  the  command  language, 
feedback,  and  the  information  display,  the  more  tangible 
components  which  make  up  the  system  hardware  and  software. 

3 .  Command  Languages 

Four  design  issues  exist  with  regard  to  the  command 
language  in  an  interactive  system  [Ref.  54;  pp.  451-458]. 
First,  hew  many  modes  should  there  be?  More  modes  lead  to 
greater  complexity  and  thus  more  errors.  Second,  a  selec¬ 
tion  ssguence  for  the  use  of  commands  and  command  parameters 
needs  to  be  determined.  In  this,  consistency  is  important. 
Third,  ac  abort  mechanism,  through  waioh  a  user  can  termi¬ 
nate  an  action  begun,  must  be  provided.  Finally,  an  error 


handling  mechanism  oust  exist.  A  wide  range  of  command 
language  styles  are  available,  including  keyboard  dialogue 
with  screen  prompts  (flexible  but  inefficient),  a  keyboard 
command  language  with  standard  command  words  and  a  simple 
syntax  (regcires  more  user  skill)  ,  use  of  function  keys 
(faster,  simpler,  but  less  flexible),  and  menu  driven  (mere 
flexible,  fewer  errors,  uses  more  screen  space)  . 

Seme  guidelines  have  been  proposed  for  designing  a 
command  language  (fief.  53:  pp.  6-7],  The  language  should  be 
consistent:  each  key  should  always  have  the  same,  cr  at 
least  an  analogous,  meaning  in  the  language.  Second,  a 
minimum  effort  should  be  all  that  ns  required  f r cm  the  user 
to  enter  the  commands,  with  the  commands  most  frequently 
used  being  the  easiest  to  enter.  finally,  use  of  only  one 
mode  is  encouraged.  However,  if  more  than  one  mode  is 

necessary,  any  cne  ccmmand  should  have  the  same  meaning  in 
each  mods  in  which  it  can  be  used. 

There  is  net  yet  agreement  on  whether  command 
languages  should  vary  depending  on  the  sxill  level  of  the 
user.  Kczelco  [fief.  62]  proposes  five  levels  of  user  moti¬ 
vation  and  expertise,  and  corresponding  types  of  command 

languages.  The  five  user  levels  are:  the  user  who  is 

learning  the  basics;  the  user  wno  warts  only  to  use  the 
system  tc  get  acceptable  results  with  a  minimum  of  learning; 
the  user  who  wants  tc  be  able  to  use  the  system  more  inde¬ 
pendently;  the  user  who  wants  to  learn  the  more  subtle 

features  of  the  system;  and  finally,  the  user  who  wants  to 
get  the  highest  possible  quality  results.  The  five  corres¬ 
ponding  levels  of  command  language  range  from  simple 
languages  using  multiple  choice  questions  and  tutorials  to 
more  complex  languages  which  use  function  keys  and  an  editor 
to  create  ccmmand  sequences  for  later  use.  While  creating 
several  languages  for  one  system  is  costly  in  terms  of  both 
time  and  money  (and  memory)  ,  Mozaico  thought  the  approach 
worth  considering. 
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Walther  and  O'Neill  [  Bef .  63]  cane  to  related 
conclusions.  Subjects  with  different  skill  levels,  working 
cn  either  teletype  (1TY)  or  cathode  ray  tube  (CHT)  terminals 
were  able  to  work  with  either  a  flexible  or  inflexible  text 
editor.  Use  of  the  flexible  language,  in  which  users  were 
able  to  abbreviate,  emit,  or  change  command  words,  among 
ether  opticas,  did  not  consistently  improve  performance. 
User  attitudes,  which  were  effected  by  all  three  variables 
(terminal  type,  language  type,  and  skill  level),  had  an 
effect  cn  performance,  as  did  each  of  the  variables  indivi¬ 
dually.  With  the  inflexible  language,  even  users  with 
little  experience  made  few  errors.  With  the  flexible 
language,  fer  all  but  those  with  the  most  experience,  a  less 
positive  attitude  led  to  mere  errors.  If  job  completion 
time  were  the  only  consider ation,  it  appeared  from  the  data 
that  it  would  be  appropriate  to  provide  more  experienced 
users  with  a  flexible  command  language  to  speed  their  work. 
However,  if  syntax  errors  were  also  a  consideration,  experi¬ 
ence  alone  was  not  enough  on  which  to  base  the  language 
decision.  Attitudes,  something  more  difficult  to  measure, 
and  mere  likely  to  change  over  time,  also  had  to  be  consid¬ 
ered.  This  is  consistent  with  dozelco's  approach  of 
providing  several  levels  of  command  language  and  leaving  the 
decision  up  to  the  user.  Unfortunately,  the  question 
remains  of  whether  this  approach  is  worth  the  cost. 

Cne  of  the  mest  important  components  of  a  command 
language  is  a  'help*  facility.  Shaeiderman  points  out  that, 
as  with  levels  of  language,  user  experience  is  net  the  best 
way  to  determine  hew  much  help  to  provide,  "since  even 
experts  may  forget  or  be  novices  with  respect  to  seme 
portions  cf  a  system"  [Bef.  61:  p.  17].  He  recommends  that 
the  user  control  the  level  cf  help  provided  through  the  help 
request  made  to  the  system.  Relies  and  Price  [Bef.  64] 
expand  cn  this,  focusing  on  the  needs  of  both  the  user  and 
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xhe  programmer  of  tas  help  facility.  Help  requests  should 
te  simple,  concise,  and  consistent,  and  the  user  should  be 
able  tc  maintain  the  current  task  during  tne  help  session. 
The  help  provided  should  be  specific  to  the  current  context, 
and  precise,  providing  only  the  information  needed. 
Additionally,  help  messages  should  be  polite,  in  the  user's 
language,  and  should  include  information  on  what  the  user 
should  dc  next,  or  how  more  detailed  information  can  be 
obtained.  From  the  programmer's  point  of  view,  it  should  be 
possible  tc  specify  the  help  routines  at  a  high  level  of 
abstraction,  separating  writing  the  text  of  the  message  from 
writing  the  rest  of  the  code.  Finally,  messages  should  be 
easy  to  write  and  easy  to  modify. 

4  •  F ee dback  and  Error  Handling 

Feedback  to  the  user  is  provided  with  regard  tc  the 
command  language  system  (a  prompt,  response  tc  a  command,  or 
error  message)  ,  the  application  database  (the  actual  task 
being  performed,  such  as  text  editing  or  CAD) ,  and  the 
display  terminal  (cursor  movement  or  character  ec he)  .  As 
pointed  cut  earlier,  timely  feedback  is  critically 
important. 

Ferfcaps  the  most  important  feedback  is  that 
regarding  errors.  User  errors  can  be  caused  by  user  over¬ 
load  (sending  too  much  information  to  the  user  at  once), 
user  ocr=dcm  or  lack  cf  motivation  (lack  of  a  timely 
response,  or  performance  cf  only  passive  operations),  or 
inadequate  instruction  and  guidance  tc  the  user  regarding 
tne  system.  Whatever  the  cause,  it  is  important  that  an 
error  message  be  given  as  soon  as  possible  after  the  error 
has  occurred.  Error  messages  should  be  short  and  to  the 
point,  but  should  net  be  negative  or  embarrassing  tc  the 
user.  In  addition  to  stating  that  taere  has  been  an  error, 
messages  should  contain  useful  information,  such  as  where 
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the  error  occurred  and  how  to  fix  it.  Finally,  it  should  be 
possible  tc  fix  the  error  with  a  minimum  amount  cf  work. 

5 .  Cispla  y 

Twc  issues  must  be  dealt  with  in  the  area  cr  infor¬ 
mation  display:  what  will  the  overall  layout  be  and  how 
will  objects  and  information  be  represented.  While  specific 
layout  car.  be  determined  by  deciding  exactly  when  the  user 
requires  what  information,  five  general  areas  are  needed:  a 
main  work  area,  an  area  for  local  editing  and  input,  an  area 
for  system  status  indicators,  a  diagnostic  area  fcr  error 
messages,  and  a  aenu/inf orm ation  area  [Hef.  51].  Blinking, 
highlighting,  cr  reverse  video  can  be  used  to  draw  attention 
to  certain  areas.  Color  can  be  used  to  lessen  apparent 
clutter  on  the  screen,  emphasize  certain  areas  or  items, 
confirm  entry  of  data  into  the  system,  or  make  identifica¬ 
tion  cf  seme  items  easier  for  the  user.  However,  if  color 
is  tc  be  used,  consideration  must  be  given  to  the  likelihood 
cf  colorblind  users  [Bef.  48]. 

aenus  can  be  used  as  part  of  the  display  as  a  conti¬ 
nuous  sccice  of  information  to  the  user,  with  color  and 
position  used  tc  group  related  items.  To  decrease  the 
amount  cf  screen  space  required,  a  hierarchy  of  smaller 
menus  can  be  used.  Additionally,  consideration  has  been 
given  tc  the  use  of  a  hierarchy  of  dynamic  menus  which 
change  as  the  dialogue  progresses  £Bef.  65].  With  this 
approach,  three  menus  are  available  on  the  screen  at  one 
time:  a  constant  menu  of  most  frequently  used  commands,  the 
dynamic  msnu,  and  a  menu  of  menus.  While  dynamic  menus  are 
possible,  it  is  not  yet  known  how  feasible  a  system  cf  this 
sort  would  be. 

Eased  on  the  above  information  on  computer  descrip¬ 
tion  languages  and  human  factors,  the  design  procedures 
followed  and  decisions  made  will  be  examined  in  Chapter 
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III.  DESIGN 


A.  EBEIINI HAST  ASSUEETIONS 

The  underlying  concepts  guiding  the  assign  of  the  system 
follow  these  stated  ly  Shneiderman: 

build  systems  that  behave  like  tools;  and 

recognize  the  distinction  between  human  reasoning  and 
computer  power  [Ref.  67]. 

Partin  echoes  these  concepts:  "  Do  not  try  to  make  the 

computer  ccccte he  with  man  in  areas  in  which  man  is  superior” 
[Hef.  48:  p.  7].  The  intent  of  the  system  is,  as  noted  by 
Ihooas  [fief.  68],  to  make  possible  the  synthesis  or  designer 
and  computer,  to  provide  (a  component  of)  a  design  system 
which  will  aid  the  designer  in  top-down  design  of  a  control 
system,  with  behavioral  descriptions  as  input. 

Several  preliminary  assumptions  were  made  regarding  the 
designer  and  the  system.  first,  the  designer  has  seme 
general  pregrammi  g  knowledge  (i.a.  is  familiar  with  the 
concepts  cf  block  structured  languages  and  top-down  design) 
but  dees  net  necessarily  know  any  specific  language  well. 
Second,  he  or  she  will  also  be  familiar  with  the  basic 
components  cf  a  control  system  -  tae  contingency/task  pairs, 
the  environmental  variables,  the  design  criteria,  and  the 
task  and  contingency  subroutines  -  and  the  information 
included  in  each  of  these  components.  Third,  the  designer 
will  use  the  system  occasionally  rather  than  continuously, 
finally,  for  its  initial  implementation,  the  entire  design 
will  be  entered  and  a  realization  produced  at  one  time. 
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Cl SIGN  C BITS fil & 


Design  criteria  sere  considered  in  twc  categories:  what 
the  system  should  be  able  to  do,  and  how  it  is  organized  tc 
do  it.  Ihe  system  sbculd  (in  order  of  decreasing  priority): 


not  require  the  designer  to  learn  a  specific  design/ 
programming  language; 

minimize  the  amount  of  repetitious,  tedious  work 
required  from  the  designer; 

minimize  actions  taken  by  the  system  implicitly  or  by 
default  which  could  lead  to  hidden  errors;  require 
explicit  confirmation  from  the  designer  whenever 
possible; 


allow  the  designer  to  make  changes  to  already 
data  without  having  to  reenter  all  of  the  data; 


entered 


be  able  to  respond  to  different  levels  of  designer 
expertise. 


Regarding  system  organization,  it  should  be: 


fully  modularized; 

implemented  as  a  minimal  set,  with  the  anility  in  the 
future  to: 


add  new  constructs  and/or  subroutines  to  the  design 
language ; 

add  new  types  and  categories  of  design  information; 

modify  the  format  in  which  the  design  data  is 
stored,  both  during  execution  and  when  written  to  a 


C.  PBELIBINSBY  DECISIONS 


Several  basic  decisions  were  necessary  prior  tc  actual 
project  design. 


1 


•  Computer  System  Selection 

The  primary  consideration  for  system  selection  was 
that  the  system  be  available  for  dedicated  work.  However, 
it  was  also  important,  since  an  interactive  system  was  to  be 
designed,  that  the  system  be  able  to  meet  most,  if  not  all 
of  tis  requirements  generally  provided  for  interactive 
systems.  Martin  [Ref.  48]  proposes,  as  considerations  when 
selecting  components  for  interactive  systems,  that  there  be 
means  for  input  by  both  the  user  and  some  document  source; 
means  for  output;  a  display  screen  wirh  appropriate  capabil¬ 
ities,  such  as  color;  tools  to  provide  the  desired  or  needed 
level  of  security;  and  tools  for  error  control.  Irby 
[Ref.  66]  expands  cn  the  required  screen  capabilities, 
giving  five  necessary  items;  the  programmer  must  be  able  to 
write  to  arbitrary  positions  on  the  screen,  be  able  to  map 
conceptual  display  primitive  operations  to  device  primitive 
operations,  be  able  tc  highlight  text  and  remove  high¬ 
lighting,  and  have  a  coordinate  input  device  which  can  be 
tracked  on  the  screen.  It  was  also  considered  desirable, 
though  net  necessary,  that  it  be  possible  to  scroll  the 
screen,  use  different  character  fonts,  and  have  a  terminal 
intelligent  enough  tc  be  aole  to  reply  to  questions  from  the 
display  terminal  interface.  The  VAX/VMS  system,  with  GIGI 
(Graphics  Image  Generator  and  Interpreter)  terminal  and 
monitor  [Ref.  69]  was  available  at  NFS,  and,  since  it  met 
most  cf  the  above  requirements,  was  selected  as  the  system 
upen  which  the  project  would  be  implemented. 

2  •  Ero  gram  mine  Languag  e 

Cf  critical  importance  was  the  ability  of  the 
language  selected  tc  provide  the  necessary  data  structures, 
primarily  records  as  elements  of  linked  lists.  Pascal,  Ada, 
and  'C*  were  considered.  Eascai  was  selected  because,  in 


addition  tc  providing  the  necessary  data  structures,  in  is 
relatively  self-documenting,  a  train  of  some  importance 
since  in  is  expected  than  future  researchers  will  continue 
work  cn  this  project.  Also,  Pascal  is  a  well  tested  and 
operational  language. 

3 .  Cesiqn  M sth ecology 

large  software  projects  require  some  organized 
approach  to  design  and  implementation.  While  'step-wise 
refinement'  is  a  frequently  used  term  with  regard  tc  soft¬ 
ware  design,  there  are  numerous  ideas  and  theories  about 
exactly  hew  to  carry  it  out. 

Cr.e  of  the  mere  commonly  used  methodologies  is  that 
developed  by  Constantine.  The  'structured  design'  method¬ 
ology  [Hef.  70]  proposes  that  systems  be  considered  as  an 
input/piccess/output  sequence  during  design.  Attention  is 
first  focused  on  whan  functions  the  system  will  perform. 
Then  these  functions  are  examined  in  terms  of  their  input 
and  output  components,  and  whan  transformation  must  occur 
between  the  two.  This  process  of  determining  function, 
decomposing  into  input/process/output,  and  then  analyzing 
each  of  these  modules  in  terms  of  function,  is  repeated 
until  the  system  has  been  completely  decomposed.  Only  at 
that  point  dees  implementation  begin. 

Structured  design  may  be  more  commonly  used  than 
ether  design  methodologies  because  in  is  easier  to  conceptu¬ 
alize  and  use,  focusing  as  in  does  on  input  and  output. 
Additionally,  its  documentation  appears  similar  tc  flow¬ 
charting,  although  there  are  significant  differences. 

Finally,  it  can  be  used  in  conjunction  with  IBM's 

Hierarchical  Input-Prccess-Out put  (HIPO)  design  documenta¬ 
tion  technicue. 
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another  software  design  approach  is  suggested  oy 
Parnas  ir.  Beferences  71  and  72,  where  he  emphasizes  concen¬ 
trating  on  the  factors  most  likely  and  least  likely  to 
change,  and  hiding  artitrary  implementation  decisions.  with 
this  approach,  specific  abstract  data  structures  are  hidden 
within  one  module,  with  module  interfaces  revealing  a 
minimum  amount  of  information  about  design  decisions.  As  a 
result  of  this  approach  to  decomposition,  it  is  possible  to 
break  a  system  down  into  levels  of  subsets,  with  the  lowest 
level  a  tasic,  minimum  subset.  Modules  can  be  placed  in  a 
loop-free  ’uses  hierarchy'  of  modules  which  use  lower  level 
modules. 

Ihis  information  hiding  and  hierarchy  of  users 
criteria  for  system  decomposition,  placing  emphasis  or.  what 
in  the  system  is  likely  to  change  in  the  future,  facilitates 
system  change  at  a  later  date.  For  this  reason  it  was 
decided  that  an  attempt  would  be  made  to  use  a  combination 
of  the  two  approaches  above.  There  will  be  attempts  in  the 
future  to  modify  or  expand  the  implementation  cf  this 
project,  ar.d  consideration  was  given  to  making  that  task  as 
simple  as  possible. 

In  line  with  the  design  guidelines  given  by  Parnas, 
consideration  was  given  tc  where  change  was  most  likely  to 
occur  in  the  design  system  being  built.  Three  areas  were 
considered:  the  format  cf  the  data  entered,  the  content  of 
the  data  entered,  and  the  command  language  used  tc  enter  the 
data.  It  was  decided  that  the  content  of  the  data  which 
would  be  entered  would  be  the  least  likely  to  change  signi¬ 
ficantly,  since  control  system  components  are  :a:  rly  stan¬ 
dard.  However,  the  format  cf  the  data,  in  both  the  source 
language  and  primitive  list  realization,  was  likely  to 
cnange.  Additionally,  it  was  likely  that  the  command 
language  would  expand  to  allow  for  different  levels  cf  user 
expertise . 


D.  SIS1I1  COMPONENTS 


1  •  C e s  1  gn  Language 


Reference  33,  in  analyzing  ISP,  provides  guidelines 
for  the  developemnt  of  the  ideal  behavioral  hardware 
description  language.  It  should: 


provide  abstraction  facilities  with  which  to  add  mere 
primiti  ves ; 

make  it  possible  to  specify  behavior  without  structure; 

support  structured  programming  constructs; 

make  it  possible  to  describe  application  specific 
information; 

have  tie  capacity  tc  express  concurrency; 

have  the  capacity  tc  describe  multiple  functions; 

have  the  capacity  to  express  synchronizing  primitives 
explicitly;  and, 

have  a  formal  semantic  definition  of  language 

operations. 


Reference  73  adds  the  further  guidelines  that  a  design 
language  should  be  suitable  for  a  variety  of  design  applica¬ 
tions,  be  easy  to  learn  and  document  through  uniformity  and 
brevity,  be  suitable  for  use  with  interactive  graphics,  and 
be  adaptable  to  more  complex  designs. 

In  the  specific  design  language  to  be  used,  a  means 
was  needed  to  input  designer  information  (name,  date,  design 
name,  comments)  ,  environmental  information  on  variables, 
contingency/task  pair  information,  criteria  information,  and 
tae  actual  functions  and  procedures  for  the  contingencies 
and  the  tasks.  Additionally,  the  language  had  to  be  able  to 
store  the  data  during  run-time  operations  in  a  format 
through  which  the  data  could  be  easily  transferred  tc  the 
IADEFI  (identification,  application  timing  for  C/T  pairs, 
design  criteria,  ar.d  environment)  file  and  the  primitive 
list  ci  subroutines  used  in  realization  of  the  design.  A 
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final  requirement  was  that  the  design  also  be  able 
documented  by  an  easily  readable  source  file. 

While  Biehl  and  Dietzinger  [Hef.  13]  used  flew 
diagrams  tc  enter  data,  the  development  of  higher  level 
languages  such  as  Pascal  and  Ada  is  leading  to  the  use  of 
languages  rather  than  flowcharts  to  explain  program  design 
in  the  Urited  States.  Additionally,  use  of  a  high  level 
language  in  design  is  closer  to  the  algorithmic  process, 
more  like  natural  language,  and  makes  the  programming  of 
software  easier  and  mere  efficient  [Ref.  74:  p.  431].  For 
these  reasons,  the  decision  was  made  tc  use  a  language, 
rather  than  pictorial  flowchart  representations,  tc  enter 
data . 

A  block  structured  programming  language  was  neces¬ 
sary  since  without  it  the  control  system  tasks  and  functions 
could  net  be  properly  entered.  With  regard  to  the  remainder 
cf  the  design  data,  the  possibility  of  having  nc  formal 
design  language,  but  instead  entering  data  directly  intc  the 
primitive  list,  was  considered.  However,  software  documen¬ 
tation  is  becoming  increasingly  important,  and  it  was  deter¬ 
mined  that  some  input  record  in  a  more  readable  form  than 
the  primitive  list  was  needed. 

As  the  design  of  the  project  progressed,  it  was 
determined  that  two  languages,  ratner  than  one,  needed  to  be 
developed.  The  first  language  was  needed  to,  as  a  minimum, 
enter  the  functions  and  procedures  involved  in  the  contin¬ 
gencies  and  tasks,  and  store  data  during  execution.  This 
can  be  considered  a  run-time  language,  and  is  written  in 
terms  cf  the  data  structures  used  during  operation  of  the 
design  system.  The  second  language  needed  was  a  more  formal 
written  language,  tc  be  considered  as  a  source  cede  record 
cf  the  design  input,  and  would  include  the  control  struc¬ 
tures  of  the  run-time  language  as  well  as  additional  format 
in forma  tier. 
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Three  language  alternatives  existed:  use  CSEL  as  it 
exists,  or  with  slight  modifications;  find  some  ether 
language;  cr  design  a  new  language,  either  from  scratch  or 
from  existing  programming  languages. 

CSDL,  or  a  modification  of  it,  was  considered  as  a 
first  alternative  in  language  selection,  since  its  BNF  nota¬ 
tion  has  been  written  cut  completely,  thus  facilitating  the 
development  of  a  compiler  or  a  syntax  directed  editor. 
However,  since  its  developmant  CSDL  has  not  become  a  widely 
used  language.  Jihile  it  is  conceptually  helpful  as  a  mcdel, 
a  dacisict  was  made  net  to  become  tied  to  the  actual  syntax 
of  CSDL,  but  tc  consider  the  second  and  third  al : ernatives. 

Concerning  the  second  alternative,  finding  another 
language,  few  other  control  system  design  languages  exist. 
Khiie  the  idea  of  using  a  derived  CONLAN  language  is 
appealing,  CCNLAN  is  still  in  the  developmental  stages. 

Consideration  was  also  given  to  developing  a  new 
language  cr  adapting  an  existing  language  (specifically  Ada) 
to  centre!  system  design  and  description.  Contributors  tc 
Heference  75  considered  the  required  components  of  a  hard¬ 
ware  description  language,  and  had  mixed  conclusions 
regarding  adaptation  or  Ada  as  a  hardware  description 
language.  However,  Ada  does  meet  many  of  the  guidelines 
offered  earlier  in  this  section  regarding  development  of 
hardware  description  and  design  languages.  Also,  Ada  has 
teen  adapted  to  be  used  as  a  program  design  language, 
FDL/Ada,  as  described  in  References  76  ana  77. 

FEL/Ada  was  developed  for  three  reasons; 

Ada  will  become  a  standard  programming  language  for 
embedded  systems,  and  use  of  PDL/Ada  will  ease  the  tran¬ 
sition  from  design  to  code; 

Ada  is  a  state  of  the  art  language,  with  support  for 
software  engineering  concepts,  and  is  also  carefully 
controlled; 

The  h da  environment  calls  for  many  support  tools  which 
will  also  be  able  tc  be  used  with  PDL/Aaa. 
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In  PDL/Ada,  components  of  Ada  were  used  as  a  basis 
for  developing  a  software  design  language  which  cculd  be 
processed  with  an  Ada  compiler  for  error  checking,  but  not 
actually  executed.  FDL/Ada  ns  a  mapping  from  PDL  into  Ada 
using: 

seme  cf  Ada  exactly  as  written; 

some  of  Ada  with  additional  constraints  on  its  use; 

some  design  information  written  as  comments  in  standard 

Ada ; 

some  features  built  from  Ada  primitives;  and 

an  extension  of  Ada's  standard  package  to  include  defi¬ 
nitions  useful  to  program  design. 

PDL/ Ada  uses  the  same  syntax  as  Ada. 

For  reasons  similar  to  those  which  led  to  the  devel¬ 
opment  cf  FDL/Ada,  the  decision  was  made  to  develop  CSD/Ada, 
adapting  Ada  to  be  used  as  a  control  system  description, 
using  CSEL  as  a  guide.  First,  it  appears  that  Ada  will 
become  a  acre  widely  used  language  as  it  is  implemented  in 
Departmsrt  of  Defense  embedded  systems.  Second,  Ada's 
strong  typing  provides  a  means  to  control  and  group  global 
and  lccal  variaoles  used  in  the  design.  Additionally,  use 
cf  Ada  makes  it  possible  to  develop  a  standard  package  of 
typss  available  for  variables  to  oe  used  in  designs. 

Following  the  PDL /Ada  model,  a  design  standard 
package  containing  acceptable  variable  types  was  written  for 
CSD/Ada.  The  Design  Standard  Package  and  a  model  for 

programs  in  CSD/Ada  can  be  found  m  Appendix  A.  The  run¬ 
time  data  structures,  written  in  Pascal,  can  be  found  in  the 
ample  mentation  cede  contained  in  Appendix  C. 
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User  Dialogue  and  Command  Language 

Given  the  design  criteria  that  the  user  not  have  to 
learn  a  specific  design/pro gramming  language,  several  alter¬ 
natives  existed  regarding  the  design  of  the  dialogue  and 
command  language.  One  was  having  the  designer  enter 
subroutine  information  using  the  algorithmic  language,  with 
an  editor  then  translating  the  input  to  CSD/Ada.  However, 
this  would  still  require  that  the  designer  learn  a  language 
for  the  subroutines  and  a  format  for  tee  remainder  of  the 
information. 

A  second  alternative  was  using  a  syntax  directed 
editor  to  lead  the  designer  through  the  full  CSD/Ada  format, 
witn  requests  for  the  appropriate  information.  This  would 
reduce  betb  the  amount  of  typing  required  from  the  designer, 
and  the  opportunities  afforded  the  designer  to  make  errors. 
A  syntax  directed  editor  (SDE),  discussed  in  References  78 
and  79,  and  also  known  as  a  grammar  driven  [Ref.  80], 
language  directed  [Ref.  81],  partially  compiling  [Ref.  82], 
or  smart  [Ref.  83]  editor,  allows  a  programmer  to  focus  on 
the  meaning  rather  than  the  punctuation  and  vocabulary  when 
writing  a  program.  One  example  is  the  Cornell  Pregram 
Synthesizer,  described  in  References  34  and  85,  used  as  a 
tool  in  teaching  programming  and  designed  to  allow  the  user 
to  concentrate  on  the  abstractions  of  a  program  rather  than 
or.  the  syntax  of  a  specific  programming  language,  thus 
supporting  top-dewa  programming. 

SCEs  are  generally  developed  from  the  3NF  notation 
for  a  language,  and,  with  prompts,  lead  the  programmer 
through  a  program  from  beginning  to  end.  Using  a  menu  or 
coded  keys,  the  programmer  types  in  the  code  for  a  specific 
component  in  or  construct  of  a  program.  The  system  then 
shows  the  user  the  format  fer  the  construct  and  gives  the 
opportunity  to  select  from  a  list  of  possible  alternatives 
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to  fill  in  the  blacks.  This  ensures  that  the 
written  with  an  SDE  are  always  syntactically  correct. 

Jihile  better  than  the  first  alternative,  this 
approach  was  also  not  ideal,  since  the  designer  would  still 
he  required  to  learn  a  specific  language  format,  if  not 
syntax.  This  would  be  appropriate  were  the  system  being 
used  as  a  teaching  tool.  However,  in  this  case  the  purpose 
cf  using  an  SDE  is  tc  make  it  possible  for  the  designer  to 
avoid  having  to  learn  either  the  syntax  or  the  format  cf  any 
specific  language. 

A  third  alternative,  use  of  a  partial  SDE,  was 
considered  and  selected  as  the  most  desirable  option.  Ihe 
SDE  would  lead  the  designer  through  the  statement  block  of  a 
subroutine  and  then  request  declaration  information  cn  vari¬ 
ables  used  in  the  subroutine.  with  this  partial  SDE,  the 
designer  would  net  have  tc  trace  through  the  entire  pregram 
structure  cf  both  declarations  and  statements,  but  could 
instead  concentrate  cn  the  statement  components  (in  CSE/Ada 
the  contingency  functions  and  task  procedures)  ,  with  the 
editor  then  cbtaining  the  remaining  declaration  type  infor¬ 
mation  needed.  Variable  types  would  be  limited,  through 
menu  selection,  to  those  types  included  in  the  CSD/Ada 
Design  Standard  package.  This  limitation  is  in  line  with 
reference  06  which  points  out  that  parsers  are  often  mere 
complex  than  needed,  and  can  be  simplified  by  limiting 
programmers  to  a  tightly  controlled  list  of  alternatives 
ratner  than  being  able  to  handle  all  possible  entries. 
Reference  32  also  contains  this  suggestion,  particularly 
regarding  types  allowed  for  variables. 

Additionally,  a  means  would  be  provided  tc  do 
semantic  type  checking  during  design  data  entry.  This 
approach  is  suggested  in  References  37,  88  and  39,  which 
describe  an  "incremental  programming  environment  (l?E)"  of 
which  an  SDE  is  only  part.  In  the  IPS,  the  SDE  and  the 
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incremental  program  constructor  work  together  interactively 
with  the  programmer.  As  parts  of  the  program  are  entered 
through  the  SDE  they  are  checked  for  semantics.  Then,  if 
the  semantics  are  correct,  intermediate  code  is  generated, 
and  the  pieces  cf  the  program  are  debugged.  It  appeared 
that  the  semantic  type  checking  of  the  IPE  could  he  applied 
to  the  control  system  design  environment,  using  the  run-time 
data  structures  developed  for  design  data  entry. 

Finally,  lists  and  prompts  would  be  used  to  obtain 
the  remaining  identification,  criteria,  and  coat ingency/t ask 
pair  information. 

Three  options  existed  as  ways  to  have  the  user  enter 
choices  during  data  entry:  type  in  the  choice  word  (either 
all  cf  it  or  part,  say  the  first  three  letters)  ,  use  a  menu, 
or  use  'softkeys'.  The  first  alternative  was  eliminated 
immediately  for  two  reasons.  One,  it  required  excessive 
typing  frcm  the  designer.  Two,  it  introduced  related  oppor¬ 
tunities  fcr  errors.  Both  of  these  consequences  could 
create  tedious,  repetitive  work  for  the  user,  contrary  to 
the  design  principles  cf  the  system. 

Kith  a  menu,  a  user  is  required  to  move  a  marker  of 
some  sort  (a  box,  an  x,  or  an  arrow)  through  a  list  of 
options  cn  the  screen,  using  cursor  position  keys,  until  it 
indicates  the  choice  being  made.  When  the  marker  is  next  to 
the  choice,  the  enter  key  is  pressed  to  indicate  the  selec¬ 
tion.  while  not  as  tedious  as  entering  whole  words,  several 
actions  can  be  required  frcm  the  user  to  get  the  marker  to 
the  desired  choice  in  the  list,  and  some  eye-hand  coordina¬ 
tion  is  required  to  knew  when  to  stop.  Fcr  that  reason  this 
option  was  also  eliminated. 

Dse  cf  softkeys  [Bef.  90]  also  involves  display  of  a 
list  cf  choices  cn  the  screen,  with  each  choice  coded  tc  a 
key  on  the  keyboard.  To  indicate  a  choice,  the  user  presses 
the  key  paired  with  it.  Possible  choices  can  be  changed  by 
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changing  the  screen  display.  The  use  of  softkeys  appeared 
to  allow  maximum  flexibility  of  choices  while  minimizing 
both  the  work  required  from  the  user  and  the  opportunity  for 
user  error.  For  these  reasons  it  was  selected  as  the 
primary  means  for  data  entry.  However,  since  use  cf  soft- 
keys  is  based  on  a  menu  type  display,  and  'menu*  is  a  mere 
ccmmcnly  recognized  term,  ’menu*  will  be  used  in  the. 
remainder  of  this  paper  to  refer  to  the  softkey  means  of 
data  input. 

3.  Screen  Disp la v 

With  the  dialogue  and  command  language  decisions 
made,  a  need  still  existed  for  a  way  to  make  the  user  aware 
of  the  choices  available  at  each  step  in  the  design  data 
entry  process.  To  avcid  user  confusion  and  maintain  consis¬ 
tency  as  far  as  where  to  look  for  input  options,  echo  of 
data  entered,  and  design  written  in  CSD/Ada,  the  decision 
was  made  to  use  a  standard  screen  format,  with  categories  of 
information  always  in  the  same  areas  of  the  screen. 
Additionally,  the  decision  was  made  to  provide  the  user  with 
a  list  cf  choices  at  each  step  in  the  data  entry  process. 
This  would  make  the  system  self-explanatory  and  minimize  the 
need  for  written  instructions  for  the  user,  following  the 
recommendations  in  Reference  52. 

E.  BASIC  INFOT  AND  OUTPUT  STEPS 

As  a  result  cf  the  design  decisions  outlined  above,  it 
was  determined  that  the  input  of  design  information  would 
have  five  modular  components: 

obtain  identification  information  througa  the  use  cf 
prompts ; 

obtain  the  contingency/task  pair 
prompts  and  menus  ana  link  it  t 
and  procedure; 
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data  through  the  use  of 
o  the  related  function 
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obtain  the  criteria  information  through  the  use  of 
prompts  and  menus; 

use  a  partial  syntax  directed  editor  to  obtain  the  i; 

statement  blocks  of  the  functions  ana  procedures,  s  a  icing 
lists  cf  variable  names  as  they  are  used; 

traverse  xb?  list  cf  variables  when  the  entry  of  each 
subroutine  is  complete,  making  up  both  the  environmental 
table  and  the  local  variable  table. 

Users  will  be  able  tc  select  the  order  in  which  they  will 
work  in  these  areas,  with  the  only  limitation  that  global 
and  local  variable  lists  be  updated  following  the  entry  of 

each  subroutine.  Cj 

1 

Cnee  the  user  decides  to  exit  the  design  entry  phase,  ] 

'J 

data  will  be  passed  to  the  second  phase  of  the  system.  In  ;• 

phase  two  the  user  has  three  options;  convert  the  data  for  j 

a  realization,  irake  changes  in  the  data,  or  write  the  data  1 

to  a  file  in  CSC/Ada  format.  If  tne  user  decides  to  convert 
the  data  tc  primitive  list  format  for  a  realization,  the  } 

system  will  check  tc  ensure  that  data  has  oeen  entered  in  ■ 

each  categcrv  and  subroutines  have  been  linked  to  the  appro-  # 

priate  ccntingency/task  data.  If  the  decision  is  made  to 
writs  the  data  to  a  file,  identification  information, 
cont ingercy/task  pair  information,  and  design  criteria  will 
be  written  as  comments  in  a  conventional  Ada  package,  with  . 

the  environment  table  and  the  subroutines  written  as  decla¬ 
rations  with  comments  ana  subroutines  in  a  conventional  Ada  • 

package.  ‘ 

M 

Chapter  Four  details  the  actual  implementation  of  this  4 

system. 
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IV.  implementation 


The  system  was  implemented  basically  as  planned  and  has 
teen  tun  successfully.  An  example  of  the  system  output  is 
included  as  Appendix  £.  Implementation  code  is  included  as 
Appendix  C. 

A.  CATA  ORGANIZATION 

Organization  of  run-time  data  into  a  hierarchy  of 
records,  as  mentioned  in  Chapter  Three,  and  shown  in  Figure 
4.1,  provided  the  tasic  structure  for  implementation.  A 
header  record,  the  root  of  the  data  tree,  was  used  to 
provide  pointers  to  identification,  criteria,  contingency/ 
task  pair,  environment,  function,  and  procedure  records. 
Multiple  records  were  able  to  be  added  in  a  linked  list  form 
for  repeating  contingency/task,  environment,  and  subroutine 
occurrences,  while  single  records  were  used  for  identifica¬ 
tion  and  criteria  data.  In  some  data  subsections,  an  occur¬ 
rence  also  became  the  root  of  a  subtree  cf  records 
containing  specific  types  of  data,  such  as  comments,  volumes 
and  monitors  for  criteria  data,  or  local  variables  and 
statements  fcr  subroutines.  Additionally,  pointers  were 
used  to  link  the  contingsnc y/task  pair  record  and  the  func¬ 
tion  and  procedure  records  to  which  it  referred. 

Q.  PGGGBAH  ORGANIZATION 

Five  major  sets  of  subroutines  were  needed  fcr  data 
entry  and  manipulation.  Listed  from  highest  to  lowest 
priority  with  regard  to  initial  implementation,  they  were: 


Figure  4.1  Hierarchy  of  Run  Ti«e  Data  Structures. 
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entry  :  c train  original  information  from  designer; 

writs  ;  read  information  from  a  record,  write  it 
permanent  file  for  storage; 

change  ;  make  changes  to  data  already  entered  in 
records ; 

convert  :  convert  data  in  the  records  to  primitive  list 
format  tor  realization; 

read  ;  read  information  from  a  file  already  created  back 
into  records  tc  work  with  it. 

Within  each  set,  lower  level  subroutines  were  closely 
matched  tc  the  record  with  which  they  would  be  used. 

Additionally,  routines  were  needed  to  handle  graphics 
displays  tc  the  screen.  This  included  instructions,  menus, 
messages,  and  display  of  data  entered. 

Subroutines  were  categorized  and  placed  in  one  cf  four¬ 
teen  files,  as  described  helcw.  Subroutines  within  each 
file  were  divided  into  categories  by  level  of  complexity, 
for  example,  primitive  routines  and  higher  level  rcutir.es 
waich  called  them,  and  by  category  cf  design  data  with  which 
they  dealt,  for  example  identification  or  contingency/task 
pair. 

1 .  Design 

DESIGN. PAS  is  the  main  fils.  It  contains  code  to 
tell  the  system  compiler  to  include  all  other  files,  and  it 
contains  the  main  subroutine  and  variables  which  it  uses. 
It  also  contains  introductory  and  instructional  subroutines, 
as  well  as  ether  subroutines  called  directly  by  the  main 
subroutine  or  for  which  ether  appropriate  files  have  not  yet 
been  created. 

2.  Beccrds 

BECCBDS.PAS  contains  the  data  types  and  data  struc¬ 
tures  created  for  the  run-time  environment.  While  it 
consists  primarily  of  records  and  pointers  to  them,  it  also 
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contains  seme  basic  type  declarations  such  as  * line_size* 
and  'nam€_size*  used  with  character  strings,  and  various 
enumerated  types  used  in  the  records. 

3 .  Scr  gen 

SCfi  EEN .  P AS  contains  the  primitive  graphics  subrout¬ 
ines,  fer  example  these  used  to  change  screen  set-up  codes 
and  alert  the  terminal  to  an  upcoming  graphics  command. 
Additionally ,  it  contains  subroutines  to  draw  the  screen, 
erase  the  total  screen  or  specific  areas  of  it,  and  position 
the  curscr  to  write  a  message. 

4 .  Text 

TEXT. PAS  consists  of  subroutines  to  write  the  title 
screen  and  instructional  screens. 

5 .  Messages 

MESSAGES. PAS  contains  one  subroutine,  'Message*, 
which  uses  a  case  statement  to  write  various  messages, 
called  ny  numoer,  to  the  message  area  on  the  screen. 

6 .  Menu  Files 

MENUS. PAS  and  MENUS  2.  PAS  contain  both  primitive  and 
higher  level  routines  to  write  menus  to  the  screen  menu 
area.  Primitive  routines  are  used  to  establish  curscr  posi¬ 
tions  for  menu  lines,  line  markers,  and  instruction  lines. 
Menu  use  instructions  are  included  as  subroutines  tc  be 
called  by  the  two  basic  types  of  menus  used  -  data  entry  or 
menu  cede  entry.  Menu  components  which  will  be  used  by  more 
than  ccs  menu  have  teen  written  as  separate  subroutines. 
Higher  level  menu  subroutines  have  been  categorized  by  the 
data  tc  which  they  apply  :  identic icaticn,  criteria, 

contingency/task  pairs,  subroutines,  and  variables.  Menus 
for  entering  variable  information  are  in  MEN  US  2;  all  ether 
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aeri us  are  iocated  in  dENUS,  along  with  code  to  tall  tne 
system  compiler  to  include  the  MENUS2  file. 

7 .  Cistla  y 

DISPLAY. PAS  consists  of  subroutines  used  tc  write 
data  entered  in  the  run-time  records  to  the  screen  for  feed¬ 
back  to  the  user.  A  lower  level  subroutine  is  used  to 
establish  standard  cursor  positions  for  each  line,  with 
higher  level  routines  categorized  oy  data  section. 

8 .  Check 

CHECK. PAS  contains  primitive  routines  called  in  both 
the  entry  cf  data  and  the  changing  of  data  to  check  char¬ 
acter  strings,  digit  strings,  and  traverse  linked  lists  of 
records  checking  for  matching  names. 

9 .  Change 

CHANGE. PAS  contains  routines  used  the  make  changes 
in  data  already  entered  and  displayed  on  the  screen. 

10.  ggtry  Files 

ENT  EE.  PAS  and  SNTEB2.  PAS  contain  sunroutiaes  used 
for  the  actual  data  entry.  ENTES  contains  primitive  rout¬ 
ines  tc  enter  character  strings,  digit  strings,  and  lines  of 
comments,  and  check  subroutine  names  already  entered,  as 
well  as  higher  level  routines  used  in  entry  of  identifica¬ 
tion  ana  ccntingency/task  data.  It  also  includes  the  main 
data  entry  routine,  and  code  to  alert  the  system  compiler  to 
include  ENIEE2.  ENTES2  consists  of  the  subroutines  used  to 
enter  criteria  data,  functions  and  procedures,  and  variable 
data . 
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FILES.  PAS  consists  of  subroutines  to  open  a  file. 


write  the  data  from  the  run-time  data  structures  to  it  ir.  a 
format  similar  to  Ada,  and  then  close  the  file.  Subroutines 
are  categorized  by  the  section  of  data  with  which  they  are 
concerned,  such  as  criteria  or  contingency /task  pairs. 
Additionally,  a  lower  level  routine  to  write  comments  to  the 
file  is  included,  and  called  by  several  of  the  higher  level 
routines. 

12.  convert 

CONVERT.  FAS  contains  routines  used  in  conversion 
from  the  run-time  data  structure  format  to  primitive  list 
format  for  realization. 

C.  SCREEN  LAYOUT 

EisFlay  of  instructions  uses  the  entire  screen.  For  ail 
ctaer  actions,  the  screen  is  divided  into  four  areas  -  menu 
and  menu  instructions ,  input,  messages,  and  data  display  - 
with  text  in  each  area  color  coordinated,  as  shown  in  Figure 

4.2. 

D.  SYSTEM  OPERATION 

System  operation  begins  with  the  display  of  a  title 
screen.  At  this  point  the  user  is  given  the  option  of 
reading  seme  general  instructions  first  or  beginning  data 
entry  imuediatsly. 

Design  data  entry  follows  a  path  from  the  mere  general 
areas  tc  the  more  specific.  Tne  user  is  allowed  to  pick  cne 
of  five  areas  in  which  tc  enter  data  -  identification, 
criteria,  ccntingency/task  pairs,  functions,  or  procedures, 
or  to  decide  to  exit  the  data  entry  section.  Once  cne  of 


Figure  4.2  Screen  Layout. 


the  data  areas  is  selected,  the  user  is  led  through  all  of 
the  data  items  needed  for  one  set  of  data  in  that  area,  with 
menus  used  to  prompt  and  limit  the  data  choices  which  can  be 
entered.  Entries  are  echoed  immediately  in  the  input  area 
cn  the  screen.  In  addition,  when  all  data  aas  been  entered 
in  a  secticc,  the  complete  set  of  data  is  written  tc  the 
screen  in  the  display  area.  Aithougn  not  yet  fully  imple¬ 
mented,  at  this  point  the  designer  will,  in  the  future,  be 
able  to  make  changes  in  the  data  displayed. 

Following  data  entry  for  a  section,  the  user  is  returned 
to  the  start  of  the  data  entry  loop  and  again  allowed  to 
pick  ca=  of  the  five  data  entry  areas  or  exit,  with  the 
condition  that  data  can  be  entered  in  the  identification  and 
criteria  areas  only  crca. 


When  -the  user  is  done  entering  data  and  decides  to  exit. 


the  system  moves  to  phase  two,  data  manipulation.  Although 
not  yet  fully  implemented,  three  options  are  available. 
Changes  can  be  made  to  the  data,  it  can  be  converted  to  a 
primitive  list  format,  and  a  realization  can  be  generated, 
or  it  can  be  writtten  to  a  permanent  file.  Again,  the  user 
continues  returning  to  these  options  in  a  loop  until  he  or 
she  decides  to  exit  from  phase  two.  The  exit  from  phase  two 
terminates  the  program. 

I.  EFBGE  CHECKING 

There  are  several  components  of  the  error  checking 
system.  In  general,  data  is  checked  when  it  is  entered. 
When  an  errcr  is  found  by  one  of  the  components,  cr  confir¬ 
mation  of  an  entry  is  needed,  a  message  is  written  tc  the 
message  area  of  the  screen  with  specific  information. 

1  •  Entry  Checks 

Entry  or  data  takes  one  of  three  forms.  The  user 
can  be  asked  to  enter  either  the  code  for  one  of  the  choices 
cn  the  menu,  a  character  string,  or  a  numerical  value.  In 
the  first  case,  if  the  user  enters  a  code  not  in  the  menu,  a 
message  will  be  written  explaining  the  error  and  asking  that 
the  entry  be  repeated.  In  the  second  and  third  cases, 
specific  subroutines  axe  used  to  checx  data  entered. 

a.  Check_Item 

’Check^Item*  is  called  when  the  user  is  entering 
identifiers,  and  it  checks  for  errors  commonly  made  in  vari¬ 
able  and  subroutine  names,  as  well  as  specific  design  system 
constraints.  It  will  give  an  error  message  and  ask  for  a 
repeat  of  the  entry  if  the  identifier  is  longer  than  ten 
characters,  does  net  start  with  a  1 


etter 


or 


cc  n tains 


a 


blanks.  Entry  cf  only  a  carriage  raturn  will  result  in 
string  of  length  zero,  and  the  user  will  be  asked  tc  repeat 
the  process. 

t.  Check_Diaits 


’Check^Digits’  is  called  when  the  user  is 
entering  nunerical  values.  It  reads  input  as  a  character 
string  and  checks  to  ensure  that  length  does  not  exceed  six 
digits  (a  size  selected  to  ensure  that  a  set  of 
contingency/task  data  can  be  writtten  as  one  lira  cf  a 
file),  ard  only  digits  have  been  entered.  It  then  calls  a 
system  library  routine  to  convert  toe  character  string  of 
digits  to  res  integer  value.  Entry  cf  only  a  carriage 
return  will  result  in  a  value  of  zero  being  assigned  tc  tne 
variable  in  guestion. 


2.  Subroutine  Name  Checking 

Eoth  contincency/task  and  subroutine  data  entry 
routines  do  extensive  subroutine  name  checking,  based  on  the 
premise  that  each  function  and  procedure  will  be  part  of 
cnly  cne  contingency/task  pair.  Subroutine  records  can  be 
entered  through  either  subroutine  entry  procedures  or 
contingency/task  pair  entry  procedures.  Beth  will  enter 
name  and  subroutine  kind.  However,  subroutine  entry  will 
enter  statements  and  set  the  ccntingency/task  pointer  to 
nil.  Contingency/task  pair  entry  will  enter  a  contingency/ 
task  pointer  and  set  the  statement  pointer  to  nil.  This 
makes  it  possible  to  determine  how  much  of  the  data  related 
to  a  subroutine  has  been  entered. 

Bhen  entering  contingency/task  pair  data,  a  check 
will  be  made  of  both  the  initialization  and  run-time  lists 
to  ensure  that  neither  the  function  or  subroutine  has  been 
included  in  a  contingency /task  pair  already  entered.  A 
check  will  then  be  made  of  the  function  and  procedure  lists. 
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If  tbs  subroutine  has  already  teen  sneered,  it  will  be 
linked  tc  the  contingency/task  pair  record.  If  not,  a  new 
subroutine  record  will  be  added,  the  name  and  kind  entered 
with  the  ether  fields  set  to  nil,  and  the  subroutine  record 
will  be  linked  to  a  cent ingency/t ask  pair  record. 

Hhen  a  subroutine  is  to  be  entered,  a  check  will  be 
made  to  see  if  t he  name  has  already  been  used.  If  It  has,  a 
check  will  be  made  of  the  statement  pointer.  If  it  is  not 
nil,  a  message  will  be  returned  that  the  entire  subroutine 
has  already  teen  entered.  If  it  is  nil,  this  record  will  be 
selected  as  the  one  in  which  to  enter  the  rest  of  the 
subroutine  data.  If  the  name  is  not  located,  a  new  record 
will  be  added,  the  ccntinge ncy/task  pointer  set  tc  nil,  and 
the  rest  of  the  subroutine  data  entered. 

3 .  Statement  Component  Checking 

Cse  of  the  partial  syntax  directed  editor  for  entry 
of  statements  ensures  that  all  statements  entered  are 
syntactically  correct.  Menus  used  to  list  options  for 
information  entered  about  variables,  such  as  precision  or 
technology,  minimize  the  chance  of  entry  of  incorrect  data 
by  the  user.  Finally,  use  of  pointers  to  link  all  variables 
in  an  expression  makes  it  possible  to  implement  mere 
detailed  type  checking  as  work  on  the  system  continues  in 
the  future. 

4 .  Ccmclet ion  Cfceck 

When  the  user  decides  to  convert  the  data  tc  primi¬ 
tive  list  format,  a  check  will  be  made  tc  ensure  that  all 
data  needed  has  been  entered.  The  first  check  will  be  of 
the  header  record,  tc  see  that  identification  and  criteria 
links  are  not  nil.  Then,  based  on  the  procedure  for 
subroutine  record  entry  described  above,  a  check  will  be 
made  cf  the  function  and  procedure  lists,  to  make  sure  that 


each  subroutine  has  both  statements  entered  and  a  pointer 
linkirg  it  tc  a  cont ingsncy/task  pair  record. 

5.  file  Notation 

As  a  reminder  to  the  designer,  and  for  future  use 
when  data  in  files  can  be  read  back  into  the  system,  'no 
data  entered'  is  written  in  sections  of  the  file  for  which 
no  data  at  all  has  been  entered. 

6.  Zxit  Check 

Since  exiting  from  phase  two  of  the  system  will 
result  in  destruction  of  the  run-time  data  structure,  a  two 
step  procedure  is  used  to  confirm  that  the  user  does  actu¬ 
ally  want  tc  terminate  the  design  process. 

Chapter  Five  will  evaluate  tha  system,  discuss  prob¬ 
lems  encountered  in  implementing  it,  and  suggest  areas  for 
future  work. 


V.  CONCESSIONS  AND  RBCQH MEN PATIO NS 

A.  GCALS  CF  THE  PROJECT 

The  goals  originally  established  with  regard  to  this 
project  were  to  design  a  workstation  which  would  not  require 
its  user  to  learn  a  specific  language  for  data  entry, 
present  a  user-friendly  approach  to  the  user,  and  produce  an 
output  of  the  data  entered  in  a  user  readable  format  which 
could  also  be  converted  to  a  primitive  list  format. 
Considering  this  project  as  a  first  implementation,  these 
goals  have  teen  met.  Use  of  the  system  has  shown  that,  for 
a  user  familiar  with  the  general  concepts  of  Hatelan's 
Computer  System  Design  Language  and  Ross'  computer  aided 
design  process,  the  screen  instruction  and  error  checking  in 
tae  system  are  sufficient  to  ensure  correct  and  complete 
data  entry.  The  preliminary  work  done  in  making  changes  to 
data  already  entered  indicates  that  it  should  be  possible  to 
expand  the  system  to  read  in  data  from  a  file  and  repeatedly 
modify  data  for  different  realizations. 

B.  EECELEH  AREAS 

While  the  system  was  implemented  successfully,  there 
were  difficulties  in  working  with  the  GIGI  terminal. 
Although  GIGI's  graphics  language  can  be  embedded  within 
Pascal,  there  was  little  documentation  available  on  new  to 
use  it  in  an  interactive  setting  and  how  to  use  it  ether 
than  tc  draw  pictures.  The  most  significant  problem 
occurred  in  code  seguencss  which  shifted  the  terminal  from 
an  interactive  Pascal  command  mode,  such  as  reading  an 
input,  to  a  graphics  command  mode,  suen  as  writing  a 
message.  A  '!'  at  the  start  of  a  sequence  cf  code  is  the 


signal  tc  indicate  tc  the  terminal  that  the  code  following 
it  is  a  grajhics  display  instruction.  While  the  '!'  at  the 
start  of  a  graphics  command  is  sufficient  to  alert  the 
terminal  within  a  sequence  cf  graphics  actions,  it  is  not 
sufficient  tc  switch  the  terminal  from  Pascal  to  graphics. 
It  was  necessary  tc  include  an  additional  wake  up  ' i ' , 
included  as  the  first  command  in  graphics  routines,  such  as 
clearing  areas  of  tte  screen,  likely  to  be  called  immedi¬ 
ately  following  Pascal  commands. 

An  additional  problem  occurred  in  writing  data  entered 
in  records  back  to  the  screen  for  display.  While  it  was  not 
difficult  tc  determine  how  to  write  a  specific  character 
string  tc  the  screen,  it  was  less  obvious  how  to  write  the 
value  cf  a  variable  or  contents  of  a  record  field  tc  the 
screen.  The  necessary  procedure  is  less  than  logical,  and 
was  fcund  through  trial  and  error  rather  than  in  available 
documentation. 

finally,  writing  the  graphics  commands  for  each  line  cf 
text  was  fcund  to  be  tedious.  Use  of  the  GIGI  macrcs  was 
considered  tut  decided  against  for  two  reasons.  when  first 
used  the  macros  were  found  to  be  unreliable,  although  this 
may  have  teen  due  tc  the  problems  of  switching  from  Pascal 
to  graphics  commands  mentioned  earlier.  More  importantly, 
the  use  cf  macros  appeared  tc  decrease,  rather  than 
increase,  readability.  This  is  because  they  can  be  identi¬ 
fied  by  cnlv  one  letter,  rather  than  by  a  word  that  indi¬ 
cates  function.  An  attempt  was  made  to  replace  the  graphics 
command  strings  with  Pascal  variables  of  type  'packed  array 
cf  characters'  which  had  been  assigned  the  graphics  command 
strings  as  values.  However,  tais  attempt  to  make  tne 
graphics  commands  mere  readable  and  reduce  required  typing 
was  unsuccessful. 
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C.  FOTUBE  BOSK 

There  ars  several  areas  for  future  work  as  a  result  of 
this  project.  In  the  field  of  computer  aided  design  system 
design  there  is  much  room  for  expansion  of  the  current 
system.  The  syntax  directed  editor  can  be  enlarged  to  allow 
for  a  full  block  structured  language.  The  ccntingency/task 
data  options  not  yet  implemented  can  be  added.  The  means 
for  data  change  and  conversion  to  primitive  list  format  can 
be  fully  implemented.  Finally,  the  means  to  read  data  in 
from  a  previously  written  file  can  be  designed  and 
implemented. 

With  regard  to  writing  of  data  to  a  file,  there  is  rcom 
for  system  modification  and  further  expansion.  The  use  of  a 
standard  file  name  and  file  type  is  based  on  use  of  an  oper¬ 
ating  system  which  numbers  file  copies,  and  retains  previous 
ccpies  until  the  user  deletes  them,  rather  than  writing  ever 
them  when  an  additional  file  of  the  same  name  and  type  is 
created.  It  would  he  beneficial  to  allow  the  user  to  enter 
the  fils  name  and  file  type  when  the  decision  is  made  to 
write  the  data  to  a  file.  This  will  allow  different 
versions  of  a  design  to  have  different  names.  Additionally, 
there  is  work  tc  be  dene  in  strengthening  the  link  between 
CSD/Ada  and  Ada.  Included  in  this  is  adding  to  the  subrout¬ 
ines  used  tc  write  the  run-time  data  to  a  file  so  that  the 
output  acre  closely  matches  Ada  format. 

In  the  field  of  user-friendliness,  there  is  opportunity 
tc  expand  and  add  flsxibilty  to  the  instructions  included 
within  the  design  system.  Introductory  instructions  can  be 
increased,  and  the  user  can  be  given  the  opportunity  to 
select  specific  instruction  screens  and  enter  and  exit  the 
instructions  at  other  than  the  beginning  and  end  of  the 
sequence  of  screens.  It  would  also  be  worthwhile  tc  take 
advantage  of  the  use  cf  case  statements  for  menu  code  entry 


LIST  OF  BEFEB2BC2S 


List  cf  Abbreviations  Used: 

ACM  Association  for  Computing  Machinery 

AFIPS  American  Federation  cf  Information-Processing 

Societies 

I3E  Institution  cf  Electrical  Engineers 

IEEE  Institute  cf  Electrical  and  Electronics  Engineers 


1.  Treu,  S.,  "A  Testbed  for  Providing  Uniformity  tc 
User-Ccmouter  Interaction  Languages,"  National  Bureau 
Cf  Standards,  1980. 


2.  Ivie,  E.  I.,  "The  Programmer's  Workbench  -  A  Machine 
fcr  Software  Development,"  Communicatio rs  of  tae  ACM, 
Vcl.  20  #10,  October  1977,  pp.  7To-  /b3’.  “ 


O'Neill,  L.  A.,  Savolaine,  C.  3.,  Thompson,  T.  J. , 
Franks.  J.  a .  .  Frieaenson,  3.  A.,  Walsh,  E.  D. , 

McDonald,  P.  H.,  Breiland,  J.  R. ,  Evans,  D.  S. , 

"Designers  Workbench  -  Efficient  and  Economical  Design 
Aids."  16th  Design  Automation  Conference  Proceedings, 
pp.  16  5=7^0,  "17127  17777 - 


4.  McWilliams,  T.  E. ,  and  widaces,  L.  C.  Jr..  "SCALD: 
Structured  Computer-Aided  Logic  Design,"  ,15th  Design 
Automation  Con rerence  Proceedings,  pp.  2 7 1  -277 , 


McWilliams,  T.  E. ,  and  widaoes,  L.  C.  Jr.,  "The  SCALD 
Physical  Design  Sun  system ,"  15th  Design  Automation 
Conference  Proceedings,  pp.  27H'rZH4,  IEE21;  19T5T“ 


Bartacci,  M.  R . ,  and  Siewiorek,  D.  P.,  "Application  of 
an  ISP  Compiler  in  a  Design  Automation  Laboratory, " 
International  Symposium  on  Computer  Hardware 
Sgsc^rpTISn  IangHagesT~.  69=75,  TE'Ee7“T97 5 . - 


66 


7 


Hafer,  L.  J.,  and  Parker,  A.  C. ,  "Register- Iransfer 
Level  Digital  Design  Automation:  The  Design  Process," 
15th  Das  ign  Automation  conference  Proceedings.  po. 


Automation  confer  enca  Proceec 


lot  a  Design  Automation  Co 

77T=2  V57“Te2e7”73737  — 


Snow,  E.  A.,  Siewiorek,  D.  ?., 


Inoma  ■ 


Design  Automation  Conference 

-22S7^EZE,"T7737 - - 


Proceedings.  p|.  220 


3 artacci,  H .  S.,  "ISP  Specifications, "  16th  Design 

Automation  Conference  Proceedings.  pp.  6  4-777  ”17777 

Parker,  A.  C.  ,  Thomas,  D. ,  Sieaiorek,  D.,  Barfcacci, 
H.#  Ha  far,  L.  ,  leive.  G.,  Kim,  J.  ,  "The  CMU  Design 
Autcraation  System."  16th  Design  Automation  Conference 
Proceedings,  pp.  / 3-BT3 ,  IE777”7777 .  ~ 

Ross,  A.  A. ,  Computer  Aided  Design  of 

Micro processor -Eased  Controllers.  Ph .  D .  Dissertation, 
University  oI"'Califor  nia ,  7  a  vis  7  June  1978. 


Rcss ,  A.  A.,  and  Loomis,  H.  H.  Jr.,  "Computer  Aided 
Design  of  Micxcprcce ssor-3ased  Systems,"  15th  Design 
Automation  Conference  Proceedings,  pp.  2 27 -2 313. "1772. 
77777 


Biehl,  G.,  and  Dietzinaer.  A.,  "Computer-Aided  Design 
of  Microprocessor- Based  Digital  Controllers," 
Microprocessors  and  Microprogramming.  Voi.  7  #5,  May 
73-577  FPT  77F=3  337  THe  71t7erIIn3s. 

Rader,  J.  A.,  "Evolution  of  the  Philosophy  and 
Capability  for  the  CAD  of  Digital  Modules."  10th 
Design  Automation  Workshop  Proceedings.  pp.  i82-23E, 
1777,"  1773.  ""  ~  " 

Armstrong,  R.  A.,  "A  CAD  User's  Perspective:  What 

Gets  Dene  Right,  Wrong,  and  Not  at  All,"  17th  Design 
Automation  Con  fere nee  Proceed in  gs ,  p.  517,  1777, ”19 So. 


Darned  aran 


and  Eason,  K.  D.  ,  "Design  Procedures 


for  User  involvement  and  User  Support,"  pc.  373-388. 
Cccmbs,  M.  J.  ,  and  Alty,  J.  L ., ' computing  Skills  am 
tae  User  Interface.  Academic  Press,  77377  ~  " 

Peled,  J.,  and  Carroll,  M.  P.  ,  "The  'Gap*  Eetween 
Users  and  Designers  of  C  A  D/C  A  a  Systems:  Search  for 

Solutions, "  18th  Design  Automation  Conference 
Proceedings,  pc.  7Q3-7U3,  1ZEE,'T"937. 


Ch  j ,  Y.,  "Why  Co  We  Need  CHDL's?,"  Computer,  Vol.  7 
#12,  December  1974  ,  pp.  18-19,  IEEE  Computer  .  ■  ‘  c  i  e  t  y . 


67 


19 


Van  Cleemput,  fa.  a.  ,  "Computer  Hardware  Description 
Languages  and  Their  Applications,"  16th  Design 
Autcaati on  Conference  Proceedings .  pp.  537-56 C ,~TZ7E7 


T51T. 


TTEc,  1T777 - * - 

Chu,  ¥. ,  "An  Algol -Li ice  Computer  Design  Language,'1 
Communications  cf  the  ACS,  Vol.  8  #10,  October  1965, 
p  c7  6X7-0757  —  ~ 

Chu,  Y. ,  Computer  Organization  and  Microprogramming. 
Chapter  1,  Vx entice- 3 aII7“73727 - * - 

Dasgupta,  S.,  "Computer  Design  and  Description 
Languages."  Advances  in  Computers  Vol.  21,  pp.  91-154, 
Academic  Press7“i337.  — 

Chu,  Y. ,  "Computer  System  Design  Description,"  19th 
Desiqn  Automation  Conference  Proceedings,  pp.  842-3577 
IIIT,  1932- - 

Hill,  F.  J.  and  Peterson,  G.  a. ,  Introduction  to 
Switching  Theory  and  Logical  Design.  Cnap£er“75,  "77 can 
Wiley  5  sons,  T9 77.  “ 

Hill,  F.  J.,  "Introducing  A  HP  L , "  Computer.  Vol.  7  #2, 
December  1974  ,  pp.  28-30,  IEEE  Computer- Society . 

Hill,  F.  J. ,  "Opdating  AHPL, "  International  Symposium 
on  Computer  Hardware  Description  Lana’uaues. 

IISCJiSlllT~PF.  22=237  IEEE, ”T375. - - *— 

Hill,  F.  J.  ,  and  Petersen,  J.  a..  Pi  git  a..  Systems  : 
Hardware  Organization  and  Design,  CnaDtez  5,  7chn 
willy “and “Ton s7~ T9 787  “  “ 


Peterson,  G.  R.,  D'Souza,  C.,  and  Hill,  F. 


"AHPL: 


Duiey,  J.  a.,  and  Dietmever,  D.  L. ,  "A  Digital  System 
Desiqn  Language  (DDL).f'  Transactions  on  Computers. 
Vcl.  C— 17,  September  ma, “pp7 — BffcBSl ,”TEET”Ccmput3r 
Society. 

Culey,  J.  8.,  and  Dietmeyer,  D.  L.,  "Translation  of  a 
DDL  Digital  System  Specification  to  Boolean 
Equations."  Transact  ions  on  Computers .  Vcl.  C-18, 
April  1969  ,  pp7  30 5-3137“ HIE  C3mpute7“ Society . 


68 


7 


Dietmeyer,  D.  I..  "Introducing  DDL,"  Computer .  Vcl. 
#2,  December  1974,  pp.  34-38,  IEEE  Computer~Scciety . 


Shiva,  S.  G.,  and  Covington,  J.  A.,  "Hodular 
Descript  ion/Simulation/Synthesis  Using  DDL,"  19th 
Desiqn  Autcmatrcn  Conference  Proceedinas.  pp.  321-7797 
HIT ,  19B77 - -  ** 


Cclladc,  a.,  and  Taiavera,  J.  A.  f  "Design  Automation 
cf  Microprocessors, "  Applications  of  Mini  and 
Microcomputers .  pp.  27-327  in3us^rial  "Electronics  anct 
Centr'd'  instrunentati on  society,  1980. 


cell,  C.  G.,  and  Newell,  A.,  "The  PMS  and  ISP 
Descriptive  Systems  for  Computer  Structures,"  Seeing 
Joint  ^  Computer  Confer  ence  Proceedings .  Vol.  367  pp. 


Bell,  C 
Headings 

19717 


G.  ,  and  Newell,  A.  , 
and  Examples .  Chapters 


Computer 


Struct  ur  es 


acSraw-BIII 


Bartacci,  M.  R. ,  "Comparison  of  Register  Transfer 
Languages  for  Describing  Computers  and  Digital 
Systems,"  Transactions  on  Computers.  Vol.  c- 24  42 , 
February  I9757~?p7  r77-l5t7,~nnJiT‘Computer  Society. 


Parker,  A.  C. ,  Thomas,  D.  E.,  Crocker,  S. ,  Catteli,  R. 
G.  G. ,  "ISPS:  A  Retrospective  View,"  4th  International 
Slliosium  on  Computer  Hardware  Descrxption~Zanguages7 
PrccsecUng  s.  pp.  2  7-2  7,  1939,  T9 77. 


Siewicrek,  D.  P. ,  Bell,  C.  G.  ,  Newell,  A.,  Computer 
Structures :  Principles  and  Examples,  Chapters-!  ana 

IT'^cGra w-Hill ,  T9 82. ”  ~  — 


Pilcty,  R . ,  Bartacci,  M.  R.,  Borrione,  D. ,  Dietmeyer, 
D.  I.,  Hill,  F.  J. ,  and  Skelly,  ?.,  "CONLAN  -  A  Formal 
Construction  Method  for  Hardware  Description 
Languages:  Easic  Principles,"  National  com  cuter 

Conference  Proceedings.  Vol.  49,  pp.  7U9-7 177“TFTT57 


Pilcty,  R . ,  Bartacci,  a.  R.,  3orrior.e,  D.,  Dietmeyer, 
D.  L.  ,  dill,  F.  J. ,  and  Skelly,  ?.  .  "CONLAN  -  A  Formal 
Construction  Metnod  for  Hardware  Description 
Languages:  Language  Derivation,"  National  Computer 

Conference  Proceedings.  Vol.  49,  ppT  7T9-2277-"3fIrS, 
79 977”  ~ 


Pilcty,  a.,  Bartacci,  a.  R.,  Bcrrione,  D.,  Dietmeyer, 
D.  L.,  Hill,  F.  J. ,  and  skelly,  ?. ,  "CONLAN  -  A  Formal 
Construction  Metnod  for  Hardware  Description 
Languages:  Language  Application,"  National  Computer 
Conference  Proceedings,  vol.  49.  pp.  279r236.  IfIPST 
7  9997 -  ^ 


43 


P-1 cty,  R.,  and  Borrione,  D.  .  "The  CONLAN  Project: 
Status  and  Future  Plans,"  19th  Design  Automation 
Conference  Proceeding  s.  pp.  2Q7"=21 2 ,‘~TS,1T7  19B77“ 


44.  Hill,  F.  J.,  A  Summary  Discussion  of  CCNLAN. 
Engineering  Experiment  “station,  CoIIeg”  of 

Engineering,  Uriversity  of  Arizona,  Tucson,  Jury  1582. 


45.  Matelan,  M.  N. ,  Automating  the  Design  on  Dedicated 
Heal  Time  Control  ~5ystems.  7CSI-7865 17~  “Tavrence 
liver mcre”La5clatof  y,  August  1 976 . 


46.  Chapanis,  A.  ,  dan- Machine  Engineering.  Wadsworth 
Publishing  Co.,  Konier  Ty7“Ia.  , “T7B57 


47.  Spence,  R.,  "Human  Factors  in  Interactive  Graphics," 
Computer  Aided  Design .  Vol.  8  #1,  Januarv  1976,  pp. 
^B-317“I?C~Sci ence  ana  Technology  Press,  Ltd. 


48.  Martin,  J. .  Design  of  Man-Computer  Dialogues, 
Prentica-Halr,  19717“  —  -  -  — — 


Black,  J.  L. ,  "A  General  Purpose  Dialogue  Processor," 
National  Ccaputer^Con  f erence  Proceedings.  Vol.  46,  pp. 


Friesen,  0.  E..  "The  Dialogue  System:  A  Tcci  for 

Testing  and  Implementing  End  User  Interfaces,"  First 
Annual  Phoenix  Conference  on  Computers  an! 
Cc mlanic allots .  ProcalUngsTTp .  152-1 557^7777“  1 9877“ 

Miller,  L.  A.,  and  Thomas,  J.  C.  Jr.,  "Behavioral 
Issuers  in  the  Use  of  Interactive  Systems," 
International  Journal  of  Kan-Machine  Studies.  Vcl.  9 
157  Be  premier  ,“79777“ pp.  5'05=5357  Tcalemic  "Press. 

Smith,  L.  B.  .  "The  Use  of  Interactive  Graphics  to 
Solve  Numerical  Problems,"  Communications  of  the  ACM . 
Vcl.  13  #10,  October  1970,  pp. “625-6 3U1 


Newman,  W.  M.  and  Sproul,  S.  F.,  Principles  of 
Interactive  Computer  Graphics .  cEapter  “  2B7 

IcBra  w^TTI,  19757  ”  “ 


55.  Eascn,  K.  D. ,  and  Damodaran,  L. ,  "The  Needs  of  the 
Commercial  User,"  pp.  115-139,  Coombs,  M.  J.,  and 
Alty,  J.  L. ,  Computing  Skills  and  the  user  Interface, 
Academic  P res  37*77  B77“  "  “  “  “  “ 


70 


56.  Fcley,  J.  D.  and  Wallace,  V.  L..  "The  Art  cf  Natural 
Graphic  Man-Machine  C cnvarsazion, "  Proceedings.  Vcl. 
62  124,  April  1574,  ?P.  462-47  1  ,  IEEZI 


57.  Miller,  G.  A.,  "The  Magical  Number  Seven,  Plus  or 
Minus  Two:  Some  Limits  cn  Our  Capacity  for  Prccessina 
Information,"  Esvchoi ogical  Review,  Vol.  63,  #2,  ppl 
81-57,  America  nts  yen  clo glc  al”2  s  s  c  ci  a  ti  on ,  1556. 


58. 


Haber,  a 
o  ‘ 


of  Computer  D 
Applications,  Vcl 
CcmpuTerHscSiety . 


,  ana  n.  sniKinson, 


Displays, "  Computer  *  Graphics  and 
’  2  *3,  May”T'5B7“ — pp. — ZT=757  1127 


59. 


Miller,  a.  E.,  "Response  Time 
Conversational  Transactions,"  Fall 
Conference  Proceedings.  Vol.  33 . TT7 
ITTTSTTstat - 


in  Man-Computer 
Joint  Computer 

1 ,  ppT  161-2 777 


60.  Spence,  a.  and  Apperley,  M. ,  "Interactive-Graphic 
Man-Computer  Dialogue  m  Computer-Aided  Circuit 
Design,"  Transactions  on  Circuits  and  Systems,  Vcl. 
CAS-24,  FeEr u ary ”T377  ,  “pp7  -67,  ~TES7  "Circuits  and 
Systems  S ociety . 


61. 


Shneiderman,  £.,  "Human 
Designing  Interactive  Systems 
December  1979,  pp.  9-19,  IEEE 


r 


Factors  Experiments  in 
»  Computer,  Vcl.  12  <M2, 
CcIfnTz?r”Socisty. 


62.  Mczelcc,  H.,  "A  Human/Ccmp ut=r  Interface  to  Acccmcdats 
learning  Stages,"  Coa a ur.i cations  of  the  ACM,  Vcl.  25 
#2,  February  1582, ^p7~17C-W7 - 


63. 


iialther,  G. 

User-Computer 

Flexibility, 

Perrormance," 

Proceedings. 


H.,  and  O’Neill, 
Interface  -  The 
Terminal  Type, 
National 

Vcl.  07  pp.  379-3 


H.  F.  Jr.,  "Cn  Line 
Effects  of  Interface 
and  Experience  on 
Computer  Conference 

HT7  aPTPS,  197TTI - 


64. 


Relies,  N.  and  Price,  L. ,  "A  iJ 
Assistance,"  5th  International 
Engineering,  pc 7  37U-Tvr37-T2IZ 


ser  Interface 
Conference 

,  77571 - 


for  Online 
cn  Software 


65 . 


Price ,  L.  , 
15th  Design 

TJE“-4  5*57”T£2 


"Design  of  Command  Menus 
Automation  conference 

2,  7937T - - 


for  CAD  Systems, 
Proceedings ,  c p 


11 


66. 


Irby,  C.  H.  , 
Manipulation, 
£rccsedinas. 


"Display  Techniques  for  I 
"  National  Computer 
Vcl.  4 T7  ? p7“7 47-2 557  a7T7 


nteractive  Text 
Conference 

S,  19BU7 - 


67.  Shneiderman,  3.,  Software  Psychology:  Human  Factors 

in  Computer  and  TnroraafTon  5ystems.  ”7amcri3ge, 
Zlssacnusetts  , ""Sinthf  op  ZuETIIner s,  7733. 


71 


63 


Tbcmas,  D.  E.,  "The  automatic  Synthesis  of  Digital 
Systems, "  Proceedings ,  Vol.  69  #10,  October  1S81,  pp. 

i2oo-i2li,“rmr - 


69.  G^GI/BeGIS  Handbook,  Digital  Equipment  Corporation, 
Haynar‘37“Hassac'Eusett s,  June,  1981. 


70.  Stevens,  if.  P..  Myers,  G.  J. ,  Constantine,  1.  1. , 

^Structured  Design,”  IBM  Systems  Journal.  Vcl.  13  #2, 


71.  Parnas,  D.  I.,  "On  the  Criteria  to  be  Used  in 
Decomposing  Systems  into  Modules."  Communications  of 
the  ACM,  Vol.  15,  #12,  December  1§72,  ppr'l‘D5T=TC53 ,  “ 


Parras,  D.  I.,  "Designing  Software  for  Ease  of 
Extension  and  Contraction,"  Transactions  on  Software 
Engineer  in  g,  Vcl.  SE-5  #2,  Marcn  77797  poT”  T2B-1 377 


73. 


Miller,  T. 

Language 

Conference 

I2I1--1T37 


J. 

for 

on 


,  and  Vellenga,  J.  H.,  "A  High  level 
VLSI  Design,"  first  Annual  Phcenix 
Computers  and  Communicaticns7~t 4CT 


74.  Manwaring,  3.  L. ,  "A  Computer  Aided  Approach  tc  the 
Design  of  Digital  System  controllers  Using 
Microprocessors,"  12th  Asilomar  Conference  on 
Circuits,  Systems,  all' Tom  purer  s.  pp.  43 1-777T7  I2EE7 


75.  Preston,  C.  H.  ,  Report  of  IDA  Summer  Study  03  Hardware 
Description  Langua ge7~  Institute  lor  Defense  Analysis, 
Science  and  Tecnnology  Division,  IDA  Paper  P-1595, 
October  1981. 


76.  Waugh,  D.  W. ,  "Ada  as  a  Design  Language,"  IBM  Software 
Engineering  E xchange .  October  1980,  pp.  8 -TIT 


77. 


Schwartz,  L.  "PDL/ADA:  A  Design  Language, 

Transition  Tool,"  IBM  Federal  Systems  Division 
Lecture,  Maval  Postgraduate  School,  Monterey, 
February  1983. 


A 

5 


78.  MacLentan,  B.  J.,  The  Automatic  Generation  of  Syntax 
Directed  Editors.  TecInicaI~7eport7  Naval"  Postgraduate 
ScIcoTTO  5OT* e  r  1 9  8 1 . 


79.  Ccmcutei:  Aided  Des ion /Software  User  Manuals:  Syntax 

UTrected  Editor  nTDEf, “system  Development  Corporation, 
T1-T3T270SU/UU7  August  1982. 


Shockley,  W.  B. ,  and  Haddow,  D.  P.  ,  A  Conceptual 
Framework  for  Gramm  ar- Driven  S  ynthe  sis7  3aHeiTs 
Thesis,  Ta var-pcslgrlluale  TcloolT uecemler  1980. 


and  Haddow, 


72 


D 


Mcr  ris ,  J .  M.  ,  and 
Language -Dir  sc  ted 
Languages,"  SIGELA M 

Machines. 


Schwartz,  M.  D. ,  '*The 
Editor  for  Block 
..  Notices.  Proceedings  of 
5s iH a  on  Text^anipuiation- 
.  15-13 ,  IssoCiation  Tor 


Design  or  a 
Structured 
the  ACM 

,  VcI7  ~T5 
Computing 


Connell,  J.  M.  ,  and  Munsil, 
a  Partially  Compiling  Edit 

il§F*^s 


4.  E. 

or,” 

ana 


,  "Considerations  for 
First  Annual  Phoenix 
UomfunicatTonsT-  pp7 


Denning,  P.  J.  .  "Smart  Editors,"  Com mun icaticr.s  of  the 
ACM,  Vol .  24  #6,  August  1981,  p p. "T9TTO7 


Teiteltaum,  T.  ,  "The  Cornell  Program  Synthesizer:  A 

Syntax  Directed  Programming  Environment."  SIGPIAN 
Notices,  Vci.  14  #10,  October  1979,  p.  75,  Association 
To  recomputing  Machines. 


Teitelbaum,  T.  ,  Beps.  T. ,  and  Horowitz, 
and  Wherefore  of  the  Cornell  Program 

Proceedings  of  the  ACM 


S. ,  "The  Why 
Synthesizer,  * 

...  .  _  SIGPLAN  SIGOA 

on ,  7c XT  T5“#57~5une  19 817 
omputing  Machines. 


Shani,  □.,  "An  Acproach  to  Graceful  Man-Machine 
communication,"  First  Annual  Phoenix  Conference  on 
Computers  and  Communications,  pp.  TT5=  1 5T7~TTTr ,  19877 


'-'i 


1 


-A 

•I 


Notkin,  D.  S.f  and  Haberman,  A.  N. ,  Software 
Development  Environment  Issues  as  Belated  to  "Tea, 
department-  of  Computer  Science,  Technical  -- a p o r t , 
Car regie-M  alien  University,  1979. 


Msdina-Mor  a, 
Prcgr ammin  g 
Engineering, 

37T=UB77  t1£e 


H.,  and  Feiler 
Environment," 
Vol.  SE-7 


,  P.  H. ,  "An  Incremental 
Transactions  on  Software 
#57  September  1 9  817”  ??• 


Medina-Mora,  E.,  Sy  qtax-Directs  d  Editing :  Towards 

Integrated  Prcgr amming  ThvironmenTs.  -  Ph7”  U7 
tJIsse  flat  ion ,  "TarnegTe-TsllonUnTversTIy,  Pi  tts  tur  gn, 
Pennsylvania,  March,  1982. 


Sarcnas,  I..  "Improving  the  Man/Machine  Interface," 
New  Electronics,  Vol.  12  #19,  ?p.  86,  89-90,  Great 

Sri tall, ~1  October  1979. 


APPENDIX  A 
CSD/ADA 


Package  design_standard  is 


type  analog  is  integer; 
type  bocln  is  boclean; 
type  ext  fixed  is  integer; 
type  ext”float  is  integer; 
type  int“fixed  is  integer; 
type  inffloat  is  integer; 


*  true/false 


end  design^sxandard; 

with  aesign_standard ;  use  d esign_standar d; 
Package  ccntrol_syst en_desi gn  is 
--  identification  block 


—  identification  data 


--  criteria  block 

—  criteria  data 

—  ccntingency/task  block 

—  contingency/task  pairs  data 

r-  environment  table 

variable  ;  type;  --  additional  global  variable  data 

—  subroutine  list 

function  name  (input)  returns  type; 
procedure  name  (input;  output)  ; 


end  ccntrcl_syst em_design; 


package  body  control_system_desigr  is 

(*  ccuplete  code  for  functions  and  procedures 
listed  here  *) 
end  ccntrcl_system_design; 
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